# What running a TLD in the DNS involves, year after year > Winning a TLD is the start. The technical, contractual and financial duties of a registry operator, in outline. Source: https://hush.partners/what-running-a-dns-tld-involves Category: Market & ICANN Published by Hush Partners. --- An application in ICANN's 2026 round absorbs a great deal of preparation: the choice of string, technical readiness, a business plan, sometimes a contest with other applicants for the same string. That preparation is correct. What tends to be underweighted is what follows if the application succeeds. Delegation is not a finish line. It is the moment a new and substantial set of operational, contractual and financial obligations begins, and they do not end until the TLD is formally wound down or passed to another operator. This article describes those obligations in outline, for project leads and their advisers who have to think past the evaluation. It covers the path from delegation to operation, the main technical and contractual duties a registry operator carries, the categories of cost involved, the people typically needed, and how the life of a DNS TLD ends. It then sets the same picture beside what is required of someone who holds the equivalent string onchain, where the obligations are different in kind. The goal is not to discourage. It is to make sure the person planning the operation understands what they are planning for. Nothing here is legal advice: the agreement you sign and your own counsel decide what applies to you.
1,616applications going forward in the 2026 round
USD 227,000evaluation fee to expect for one application; advisers and the running of the registry come on top
Noneannual renewal fee on a Freename onchain TLD

Application count from trade press reporting; evaluation fee from ICANN's new gTLD program pages; renewal fee from the Freename registry.

## From contract to delegation: the pre-launch sequence An application that passes evaluation does not produce a working TLD. It produces an invitation to sign a Registry Agreement with ICANN, the contract under which the TLD will be run. Both the signature and the delegation that follows are subject to time limits set by the program, so the period between the two is not open-ended. In practice it is occupied by a structured sequence of technical gates. The first gate is pre-delegation testing. Its purpose is to verify that the applicant can actually run the registry it described in its application, against the technical and operational criteria of the program's applicant guidebook. The testing looks at the DNS server infrastructure and at the registry system itself, and it must be passed before the string is placed in the DNS root zone, the list of TLDs that the ICANN DNS recognizes. The second gate concerns trademark owners. A new registry is connected to the Trademark Clearinghouse, the central record of verified marks used by the program, and that connection is tested. The operator also files its startup information: when its launch phases will run and what its registration policies are. A TLD that will issue names to the public then opens in phases. The Sunrise period comes first: owners of marks recorded in the Trademark Clearinghouse may register the matching names before anyone else. A Trademark Claims service follows, which warns a would-be registrant that a name matches a recorded mark and notifies the mark owner if the registration goes ahead. Only then does general registration open. A dotBrand, a TLD that an organization runs for its own use and that does not sell names to third parties, is treated differently on this point, since there is no public to open to. The practical implication is that a registry operator must have its technical infrastructure and its registrar relationships in place before it asks for a delegation date, not after. Applicants who have not modeled this sequence tend to lose time to it. ## Technical operation and the role of a back-end provider Running a gTLD in the DNS means operating a shared registration system, the authoritative database of the names registered under the TLD, and publishing the TLD's zone from it. The zone is the file that tells the rest of the DNS where each name under the TLD is served. Around that core sit several services that must run without interruption. - **A registration interface.** Registrars create, renew and transfer names through EPP, the Extensible Provisioning Protocol, a standard machine interface between registrars and the registry. - **Authoritative DNS.** Name servers, distributed across several locations, answer queries for the TLD at all hours. - **DNSSEC.** The zone is cryptographically signed so that resolvers can verify the answers they receive, which means keys to generate, protect and rotate. - **Registration data access.** The registry answers lookups about registered names through RDAP, the Registration Data Access Protocol. - **Data escrow.** Copies of the registry database are deposited with an independent escrow agent on a fixed schedule. - **Abuse handling.** The registry keeps a point of contact for abuse reports and a process to act on them. Most registry operators do not build this infrastructure themselves. They contract a registry services provider, often called a back-end provider, to supply some or all of it. The division of roles is the point to understand. The provider is the technical engine. The registry operator remains the contracting party toward ICANN and carries every compliance obligation, whichever functions it has subcontracted. If the provider fails a service level, ICANN's counterparty is still you. That has consequences for how the provider contract is written. The agreement with ICANN expects subcontractors to be held to the same obligations as the operator, and it expects ICANN to be told in advance of a material subcontracting arrangement. The provider contract therefore needs service levels at least as strict as those you owe, access to the data you need for your own reporting, cooperation in an audit, and an exit clause that lets the registry be moved to another provider without a break in service. Changing provider during the life of a TLD is possible, but it is a project with its own process and notice, and it is far easier when the first contract anticipated it. The service levels are not decorative. ICANN measures the availability of the DNS, of the registration interface and of the registration data service, along with response times, against specifications attached to the Registry Agreement. Falling below them opens a formal compliance process, and a sustained failure of a critical function can lead to emergency measures described further down. ## The Registry Agreement: a binding contract for the life of the TLD The Registry Agreement is the foundational contract between ICANN and each registry operator. It defines the rights, obligations and operating requirements attached to the TLD, and those obligations last as long as the operator holds it. The agreement is, in substance, a standard form. ICANN applies a base agreement across the operators of the program, and an applicant should not plan on negotiating its core terms. There are two main ways in which one operator's agreement differs from another's. Commitments made in the application, and provisions specific to a community or a dotBrand, can become part of the contract. And an operator that wants to offer a new registry service after signing asks for it through a formal evaluation process. The main categories of obligation are these: - **Technical standards.** Conformity with the registration protocol, IPv6 support, DNSSEC, and the guidelines for internationalized names where the TLD allows them. - **Rights protection.** The Sunrise period, the Trademark Claims service and the ongoing connection to the Trademark Clearinghouse, plus the dispute procedures available to trademark owners after launch. - **Data escrow.** Regular deposits of registry data with an approved agent, so that registrations can be moved to a successor if the registry fails. - **Continued operations instrument.** A financial backstop, arranged by the operator, that pays for the critical functions of the registry for a period if the operator cannot continue. - **Code of conduct.** Rules on how the registry treats registrars, including even-handed access for those it accredits, with adaptations for a TLD used only by its own organization. - **Public interest commitments.** Undertakings that turn promises made in the application into contractual obligations, enforceable by ICANN and open to complaints from parties harmed by a failure to comply. Two features of this list deserve attention when you plan. First, almost none of it is optional and almost none of it scales down to zero: a TLD with very few names still signs its zone, deposits its data and files its reports. Second, the agreement changes over its life. Amendments that apply to all operators are adopted through ICANN's processes, and consensus policies developed by the ICANN community bind operators as they come into force. You are signing up to a contract and to the process that revises it. The [glossary](/glossary) gives plain-language definitions of the terms used on this site, including the onchain ones that appear later in this article. ## Reporting and compliance: a standing obligation Compliance with the Registry Agreement is not an annual audit. It is a continuous operational state, verified through recurring reports and through ICANN's own monitoring. The operator files regular reports with ICANN, in a fixed format and to a fixed deadline, for each TLD it runs. In outline they cover the activity of the registry: registrations, renewals, transfers and deletions by registrar, and the performance of the technical functions. A back-end provider usually prepares the figures. The operator is the one that owes them and answers for their accuracy. Security is a separate line of work. The operator is expected to analyze periodically whether names in the TLD are being used for threats such as phishing, pharming, malware and botnets, to keep a record of what it found and what it did about it, and to produce that record when ICANN asks. A TLD open to the public needs a real process here: someone who reads the reports, decides, acts with the registrar concerned, and documents the outcome. ICANN may also audit. On request, the operator has to produce the documents and data that show it complies, within the time allowed. ICANN's compliance function handles complaints from registrars, registrants and third parties, and can open a formal process against an operator for missed service levels, failures of zone file access, missed escrow deposits or an inadequate response to abuse. Public interest commitments have their own dispute procedure. The compliance posture is therefore not something an operator can hand off informally. It requires a named owner, written procedures and records kept from the first day. An operator that can show what it did and when is in a very different position, when a notice arrives, from one that has to reconstruct it. ## Categories of recurring cost A registry operator carries several distinct categories of cost that repeat for as long as the TLD is active. This section describes the categories and attaches no figures, because the amounts vary substantially with the type of TLD, the expected volume of names, and the operator's choices between building and buying. **ICANN fees.** The Registry Agreement requires the operator to pay recurring fees to ICANN from delegation onward. Their structure and amounts are set in the agreement and can change through ICANN's processes. Read the fee article of the agreement you will actually sign, and budget from it. **Back-end infrastructure.** Whether the operator builds its own registry system or contracts a provider, the cost of the registration system, the DNS, DNSSEC signing, the registration data service and abuse tooling recurs for as long as the TLD exists. Provider pricing models differ, and some depend on the number of names. An operator that builds its own infrastructure replaces vendor fees with capital and staff. **Data escrow.** Escrow is a mandatory service supplied by a third party, with its own recurring cost. **Rights protection.** The connection to the Trademark Clearinghouse, participation in the dispute procedures that apply to the TLD, and the upkeep of an abuse contact and response process all carry direct costs. **Continued operations instrument.** Funding the financial backstop is a commitment that sits outside the operating budget line but must be planned for, and maintained. **Legal and policy.** ICANN policy evolves. Following consultations, responding where your TLD is affected, and keeping compliance documentation current require standing attention from someone qualified. **Registrar relationships.** A market TLD, one that issues names to third parties, sells them through ICANN-accredited registrars. Managing those relationships (agreements, technical onboarding, commercial terms, promotions) carries administrative and commercial cost. A dotBrand that registers names only for its own organization has a simpler picture, although its names still go through a registrar. Two observations help when you turn these categories into a budget. The costs are largely fixed: most of them are owed whether the TLD carries ten names or a great many, so a low-volume TLD has a high cost per name by construction. And the revenue side, for a market TLD, depends on registrars choosing to carry the TLD and on registrants renewing, neither of which the operator controls. For a dotBrand there is no revenue line at all, and the case rests on what the organization gains from running its own space. The [comparison of a dotBrand and an onchain TLD](/dotbrand-vs-onchain-tld) sets the two models side by side on these dimensions. ## People needed to operate a registry The staffing a registry requires depends on whether it is a market TLD issuing names to the public, a community TLD serving a defined group, or a dotBrand used only internally. The functions below apply to all three, though the scale differs, and in a small operation one person may hold several. **Policy and compliance.** Someone must own the ICANN relationship, follow policy work, manage the reports, answer compliance inquiries and keep the documentation an audit would ask for. In a small operation this is often the general counsel's office or a retained adviser. In a larger one it is a dedicated function. **Technical oversight.** Even where a back-end provider runs the infrastructure, the operator needs someone internal who can read service level reports, manage the provider, review security findings and handle escalations. An operator that builds its own infrastructure needs a full technical team with cover at all hours. **Registrar and registrant relations.** A market TLD needs people to bring registrars on, support them, and administer the rights protection mechanisms. After launch, disputes over individual names are mostly handled under the UDRP, the Uniform Domain-Name Dispute-Resolution Policy, a procedure that binds registrants through their registration agreements and that registrars implement. The registry's part is usually limited, but it has to be ready to act on a decision. **Finance.** ICANN fees, escrow, provider invoices and the continued operations instrument need a finance contact who understands the terms of the agreement and can plan for changes. **Legal.** The Registry Agreement is a long contract with a life of its own. New registry services require filings. Trademark disputes, abuse complaints and amendments all create legal work. Operators without in-house capacity usually retain counsel who know ICANN contracts. An organization that has not run a registry before will often underestimate the policy and compliance load relative to the technical one. The technical problems are largely solved by contracting a capable provider. The compliance and policy obligations belong to the operator and cannot be outsourced in the same way. A useful test before applying is to write down a name beside each function above, and to ask what happens when that person leaves. ## Ending a DNS TLD: termination and transition A TLD in the DNS can end in several ways, and none of them is a simple switch. The Registry Agreement can be terminated by ICANN on defined grounds, such as an uncured breach or the insolvency of the operator, and by the operator under the conditions the agreement sets. When that happens, ICANN decides, after consulting the operator, whether the TLD is handed to a successor operator under its registry transition process or is retired. The interests of the registrants weigh heavily in that decision. A dotBrand is in a particular position: since the names belong to the organization itself, the agreement gives it more say over whether its TLD may pass to someone else. A voluntary exit, where the operator simply wishes to stop, requires notice to ICANN, an orderly wind-down, and either a transfer of the TLD to a successor or its removal from the DNS root zone. The names registered under the TLD must be dealt with: registrants informed, renewals handled, registrars kept in the loop until the last name lapses or moves. Data escrow exists to make this possible. An operator may also assign its agreement to another party, for example when the TLD is sold as a going concern. Assignment needs ICANN's consent, and the incoming operator has to show it can meet the same requirements. For the case where a registry fails without warning, ICANN keeps emergency back-end registry operators under contract. If a critical function of a registry stays below the emergency thresholds of the agreement, ICANN may appoint one of them to run those functions until the operator shows it can resume, or until a successor or a wind-down is arranged. The continued operations instrument is what pays for that period. The practical point for planners: an operator that has issued names to registrants has obligations to them that do not end when it decides it no longer wants to run the registry. The wind-down is itself a compliance event, carried out under ICANN's oversight. It belongs in the plan from the start, with a view on who would take the TLD over and on what terms. ## The same string onchain: what its holder must do An onchain TLD on a registry such as Freename is not a delegation. It is a token recorded onchain and held in a wallet, and whoever controls the wallet controls the TLD. What its holder is required to do differs in kind from what a DNS registry operator is required to do. There is no Registry Agreement with a coordinating body. There are no service levels reported to an authority, no periodic filings, no Sunrise period, no Trademark Clearinghouse connection, no data escrow and no continued operations instrument. The holder maintains no registrar channel and answers no ICANN compliance inquiry, because none of those structures exist onchain. A Freename TLD also carries no annual renewal fee. What the holder does need to manage is a shorter list. **Wallet security.** The record of who holds the TLD is public, and a block explorer lets anyone verify it. Control rests on the private key of the wallet. If the key is lost or compromised, so is the TLD, and no authority can restore it. A multisignature wallet, where several keys must approve a transaction, is a common way for an organization to avoid depending on one person or one device. **Issuance policy.** Names under the TLD come from one source: its holder, and nobody else can create them. The holder decides who may have a name, at what price and on what conditions, with no outside body approving or reviewing those rules. That is flexibility, and it also means the holder answers for how the namespace is used. The [operators](/operators) page is written for those who run a market TLD as a namespace in this way. **Royalties.** Freename has a royalty program under which a share of every registration fee paid for a name under a TLD goes to that TLD's holder. The share is advertised at up to half and depends on the registry's current terms and on its activation conditions, so a holder should read them before building a revenue forecast on it. The forecast also needs a cost line. The absence of an annual renewal fee concerns the TLD, whereas taking part in the royalty program carries an annual cost set by the registry. Some TLDs were registered under earlier terms that include the program for life, and whether those terms carry over to a buyer is a point to confirm with the registry before closing. **Activation.** What the TLD does in practice (names that resolve in wallets, payments to a name, websites, identities for AI agents) depends on what the holder sets up and keeps configured. The [list of what is live](/whats-live) gives each capability with its source. **Legal exposure.** Holding or using a string that matches someone else's trademark creates legal risk onchain as it does anywhere. Trademark law does not stop at the DNS, and how it applies to an onchain TLD varies by country. Your own counsel decides. The limits of the onchain model belong in the same picture. A name under an onchain TLD is not part of the ICANN DNS root, which means a standard browser will not open it unless support has been added, and that support is partial and changes. The contractual machinery described in the earlier sections is also what gives registrants and trademark owners in the DNS their protections: escrow, a successor process, mandatory dispute procedures. An onchain TLD has none of that by default. Where universal resolution or that institutional framework is what you need, the DNS is simply the better instrument. The two models are therefore not a heavy and a light version of the same thing. A DNS registry operator carries a standing institutional obligation, enforced by contract with ICANN. An onchain holder carries the obligations of the owner of an asset: keeping it safe, using it responsibly, respecting the law. The table sets the main duties side by side. | Duty area | DNS registry operator | Onchain TLD holder | |---|---|---| | Governing contract | Registry Agreement with ICANN | None with ICANN; the registry's terms | | Technical service levels | Mandatory, measured and reported | No authority sets them | | Periodic reporting | Required, fixed format and deadline | Not required | | Sunrise and Claims | Mandatory for market TLDs | Not required | | Data escrow | Mandatory, ongoing | Not required | | Continued operations instrument | Required | Not required | | Compliance audits | Possible at ICANN's request | Not applicable | | Who issues names | Registry, through accredited registrars | The holder only | | Exit | Wind-down or transition under ICANN oversight | Transfer of the token | | Recurring fee to the authority | Recurring fees to ICANN | No annual renewal fee on Freename | | Resolution | Universal in the DNS | Partial, where supported | ## Planning for operation before planning to apply The window of the 2026 round closed on August 12, 2026. The expected evaluation fee was USD 227,000 per application, and that figure covers neither advisers nor the registry operation described above. An applicant that passes evaluation and then finds it cannot sustain the operation has spent the fee and will spend more to unwind a commitment it was not ready to carry. Whether you are preparing for the contract that follows this round or weighing a later one, the sound sequence is the same: model the operating state first. In practice that means five pieces of work. 1. Choose the back-end provider, and negotiate the service levels, data access and exit clause discussed above. 2. Put an estimate, from real quotes, beside each recurring cost category, for the life of the agreement and not for the first year alone. 3. Name the people who will own compliance, policy, technical oversight and finance. 4. Decide what the TLD is for: a [trademark TLD](/trademark-tlds) run for the organization's own use, a market namespace issuing names to a sector, or a community namespace with eligibility rules. Each implies a different operating model and a different cost structure. 5. Write the exit: who could take the TLD over, and what a wind-down would require. If that exercise leads your organization to look at the onchain equivalent of its string, alongside a DNS TLD or instead of one, the questions change rather than disappear. The planning work becomes custody, issuance rules and activation. The page on [activation after a transfer](/post-transfer-activation) describes putting an onchain TLD to work once it is acquired, and the free Launch Roadmap tool on this site builds a [roadmap for a newly acquired TLD](/activation-roadmap). ## Questions people ask ### Does a dotBrand TLD have the same obligations as a market TLD? Mostly yes. A dotBrand operates under a specific part of the Registry Agreement that adapts the rules to a TLD that does not sell names to the public, notably on the Sunrise period, on the registrar channel and on what happens to the TLD if the agreement ends. The core technical obligations remain: DNSSEC, service levels, data escrow, reporting to ICANN and the continued operations instrument. The load is lighter than that of a market TLD and it is not trivial. ### Can a registry operator change its back-end provider after delegation? Yes, through a formal process. ICANN is notified in advance of the change, the incoming provider must meet the technical requirements, and the migration must not interrupt service. The operator remains the contracting party throughout and cannot pass its compliance obligations to either provider. ### What happens to registered names if a DNS TLD is wound down? That depends on the outcome of ICANN's transition process. If a successor operator takes the TLD, the names continue under it, and the escrowed data is what allows the registrations to be carried over. If the TLD is removed from the DNS root zone, its names stop resolving. Registrants are informed beforehand, and the timetable is settled with ICANN, not by the departing operator alone. ### Does holding an onchain TLD give any right to the same string in the DNS? No. The two systems are separate. An onchain TLD is a record on a registry such as Freename, and a DNS TLD exists only by delegation from ICANN under a Registry Agreement. Holding one confers no claim on the other, and an organization that wants both has to obtain each through its own route. ### Where does Hush Partners fit into this? Hush Partners is a private desk for onchain TLDs and has no role in ICANN applications. An organization that has concluded the onchain model fits its goals can mandate the desk to find and approach the holder of the TLD that matches its brand or sector, with every exchange covered by a standard mutual NDA. The desk is reached through the [contact form](/contact) only.