Hubbry Logo
Top-level domainTop-level domainMain
Open search
Top-level domain
Community hub
Top-level domain
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Top-level domain
Top-level domain
Top-level domain
View on Wikipedia
from Wikipedia
"TLD" and "TLDN" redirect here. For other uses, see TLD (disambiguation).
For a list of all top-level domains, see List of Internet top-level domains.
See also: Country code top-level domain

Internet history timeline

Early research and development:

Merging the networks and creating the Internet:

Commercialization, privatization, broader access leads to the modern Internet:

Examples of Internet services:

A top-level domain (TLD) is one of the domains at the highest level in the hierarchical Domain Name System of the Internet after the root domain.[1] The top-level domain names are installed in the root zone of the name space. For all domains in lower levels, it is the last part of the domain name, that is, the last non-empty label of a fully qualified domain name. For example, in the domain name www.example.com, the top-level domain is .com. Responsibility for management of most top-level domains is delegated to specific organizations by the ICANN, an Internet multi-stakeholder community, which operates the Internet Assigned Numbers Authority (IANA), and is in charge of maintaining the DNS root zone.

History

[edit]

Originally, the top-level domain space was organized into three main groups: Countries, Categories, and Multiorganizations.[2] An additional temporary group consisted of only the initial DNS domain, .arpa,[3] and was intended for transitional purposes toward the stabilization of the domain name system.

Types

[edit]

As of 2015, IANA distinguishes the following groups of top-level domains:[4]

Countries are designated in the Domain Name System by their two-letter ISO country code;[5] there are exceptions, however (e.g., .uk). This group of domains is, therefore, commonly known as country-code top-level domains (ccTLD). Since 2009, countries with non–Latin-based scripts may apply for internationalized country code top-level domain names, which are displayed in end-user applications in their language-native script or alphabet, but use a Punycode-translated ASCII domain name in the Domain Name System.

Generic top-level domains (formerly categories) initially consisted of .gov, .edu, .com, .mil, .org, and .net. More generic TLDs have been added, such as .info.

The authoritative list of current TLDs in the root zone is published at the IANA website at https://www.iana.org/domains/root/db/.

Internationalized country code TLDs

[edit]

An internationalized country code top-level domain (IDN ccTLD) is a top-level domain with a specially encoded domain name that is displayed in an end-user application, such as a web browser, in its language-native script or alphabet (such as the Arabic alphabet), or a non-alphabetic writing system (such as Chinese characters). IDN ccTLDs are an application of the internationalized domain name (IDN) system to top-level Internet domains assigned to countries, or independent geographic regions.

ICANN started to accept applications for IDN ccTLDs in November 2009,[6] and installed the first set into the Domain Names System in May 2010. The first set was a group of Arabic names for the countries of Egypt, Saudi Arabia, and the United Arab Emirates. By May 2010, 21 countries had submitted applications to ICANN, representing 11 scripts.[7]

Infrastructure domain

[edit]

The domain .arpa was the first Internet top-level domain. It was intended to be used only temporarily, aiding in the transition of traditional ARPANET host names to the domain name system. However, after it had been used for reverse DNS lookup, it was found impractical to retire it, and is used today exclusively for Internet infrastructure purposes such as in-addr.arpa for IPv4 and ip6.arpa for IPv6 reverse DNS resolution, uri.arpa and urn.arpa for the Dynamic Delegation Discovery System, and e164.arpa for telephone number mapping based on NAPTR DNS records. For historical reasons, .arpa is sometimes considered to be a generic top-level domain.[8]

Reserved domains

[edit]

A set of domain names is reserved[9][10] by the Internet Engineering Task Force as special-use domain names. The practice originated in RFC 1597 for reserved address allocations in 1994 and reserved top-level domains in RFC 2606 of 1999, with additional reservations in later RFCs. These reserved names should not be used in production networks that utilize the global domain name system.

Reserved Top-Level Domains
Domain Reserved by Reserved for
.example RFC 6761[11] use in examples
.invalid RFC 6761[11] use in invalid domain names
.localhost RFC 6761[11] avoiding conflict with the traditional use of localhost as a hostname
.test RFC 6761[11] use in tests
.local RFC 6762[12] link-local host names that can be resolved via the multicast DNS name resolution protocol
.onion RFC 7686[13] self-authenticating names of Tor onion services
.internal ICANN[14][15] private application use
.alt RFC 9476[16] alternative (non-DNS) namespaces

Historical domains

[edit]

In the late 1980s, InterNIC created the .nato domain for use by NATO.[17] NATO considered none of the then-existing TLDs as adequately reflecting their status as an international organization. Soon after this addition, however, InterNIC also created the .int TLD for the use by international organizations in general, and persuaded NATO to use the second level domain nato.int instead. The nato TLD, no longer used, was finally removed in July 1996.[18]

Other historical TLDs are .cs for Czechoslovakia (now using .cz for Czech Republic and .sk for Slovakia), .dd for East Germany (using .de after reunification of Germany), .yu for SFR Yugoslavia and Serbia and Montenegro (now using .ba for Bosnia and Herzegovina, .hr for Croatia, .me for Montenegro, .mk for North Macedonia, .rs for Serbia and .si for Slovenia), .zr for Zaire (now .cd for the Democratic Republic of the Congo), and .an for Netherlands Antilles (now .aw for Aruba, .cw for Curaçao and .sx for Sint Maarten). In contrast to these, the TLD .su has remained active despite the collapse of the Soviet Union that it represents. Under the chairmanship of Nigel Roberts, ICANN's ccNSO is working on a policy for the retirement of ccTLDs that have been removed from ISO 3166.

Proposed domains

[edit]
Further information: Proposed top-level domain

Around late 2000, ICANN discussed and finally introduced[19] .aero, .biz, .coop, .info, .museum, .name, and .pro TLDs. Site owners argued that a similar TLD should be made available for adult and pornographic websites to settle the dispute of obscene content on the Internet, to address the responsibility of US service providers under the US Communications Decency Act of 1996. Several options were proposed including xxx, sex and adult.[20] The .xxx top-level domain eventually went live in 2011.[21]

An older proposal consisted of seven new gTLDs: arts, firm, .info, nom, rec, .shop, and .web.[22] Later .biz, .info, .museum, and .name covered most of these old proposals.

During the 32nd International Public ICANN Meeting in Paris in 2008, ICANN started a new process of TLD naming policy to take a "significant step forward on the introduction of new generic top-level domains".[23] This program envisioned the availability of many new or already proposed domains, as well as a new application and implementation process.[24] Observers believed that the new rules could result in hundreds of new gTLDs being registered.[25]

On 13 June 2012, ICANN announced nearly 2,000 applications for top-level domains, which began installation throughout 2013.[26][27] The first seven – bike, clothing, guru, holdings, plumbing, singles, and ventures – were released in 2014.[28]

Rejected domains

[edit]

ICANN rejected several proposed domains to include .home and .corp due to conflicts regarding gTLDs that are in use in internal networks.

Investigation into the conflicts was conducted at ICANN's request by Interisle Consulting. The resulting report was to become known as the Name Collision[29] issue, which was first reported at ICANN 47.[30]

Dotless domains

[edit]
.org[.] is a node in the DNS tree, just like wikipedia.[org.] and en.[wikipedia.org.]. As such, it has its own DNS records.

Due to the structure of DNS, each node in the tree has its own collection of records, and since top-level domains are nodes in DNS, they have records of their own. For example, querying org itself (with a tool such as dig, host, or nslookup) returns information on its nameservers: 

QUESTION
org. IN ANY
ANSWER
org. 21599 IN NS a0.org.afilias-nst.info.
org. 21599 IN NS a2.org.afilias-nst.info.
org. 21599 IN NS b0.org.afilias-nst.org.
org. 21599 IN NS b2.org.afilias-nst.org.
[…]

Dotless domains are top-level domains that take advantage of that fact, and implement A, AAAA or MX DNS records to serve webpages or allow incoming email directly on a TLD – for example, a webpage hosted on http://example/, or an email address user@example.[31]

ICANN and IAB have spoken out against the practice, classifying it as a security risk among other concerns.[32] ICANN's Security and Stability Advisory Committee (SSAC) additionally claims that SMTP "requires at least two labels in the FQDN of a mail address" and, as such, mail servers would reject emails to addresses with dotless domains.[31]

ICANN has also published a resolution in 2013 that prohibits the creation of dotless domains on gTLDs.[33] ccTLDs, however, fall largely under their respective country's jurisdiction, and not under ICANN's. Because of this, there have been many examples of dotless domains on ccTLDs in spite of ICANN's vocal opposition.

As of July 2025, that is the case of:

In 2023, it used to be the case of:

Other ccTLDs with A or AAAA records, as of July 2025, include: .cm, .tk and .ws.

A similar query to org's presented above could be made for ai, which showed A and MX records for the TLD: 

QUESTION
ai. IN ANY
ANSWER
ai. 21599 IN A  209.59.119.34
ai. 21599 IN MX 10 mail.offshore.ai.
ai. 21599 IN NS anycastdns1-cz.nic.ai.
ai. 21599 IN NS anycastdns2-cz.nic.ai.
ai. 21599 IN NS pch.whois.ai.
[…]

Historically, many other ccTLDs have had A or AAAA records. On 3 September 2013, as reported by the IETF, they were the following:[34] .ac, .dk, .gg, .io, .je, .kh, .sh, .tm, .to, and .vi.

New TLDs

[edit]

Following a 2014 resolution by ICANN, newly registered TLDs must implement the following A, MX, TXT, and SRV apex DNS records – where <TLD> stands for the registered TLD – for at least 90 days:[35] 

<TLD>. 3600 IN MX  10      your-dns-needs-immediate-attention.<TLD>.
<TLD>. 3600 IN SRV 10 10 0 your-dns-needs-immediate-attention.<TLD>.
<TLD>. 3600 IN TXT         "Your DNS configuration needs immediate attention see https://icann.org/namecollision"
<TLD>. 3600 IN A           127.0.53.53

This requirement is meant to avoid domain name collisions when new TLDs are registered. For example, programmers may have used custom local domains such as foo.bar or test.dev, which would both collide with the creation of gTLDs .bar in 2014 and .dev in 2019.

While this does create apex DNS records of type A and MX, they do not qualify as a dotless domain, as the records should not point to real servers. For instance, the A record contains the IP 127.0.53.53, a loopback address (see IPv4 § Addressing), picked as a mnemonic to indicate a DNS-related problem, as DNS uses port 53.[36]

Pseudo-domains

[edit]
Main article: Pseudo-top-level domain

Several networks, such as BITNET, CSNET, and UUCP, existed that were in widespread use among computer professionals and academic users, but were not interoperable directly with the Internet and exchanged mail with the Internet via special email gateways. For relaying purposes on the gateways, messages associated with these networks were labeled with suffixes such as .bitnet, .oz, .csnet, or .uucp, but these domains did not exist as top-level domains in the public Domain Name System of the Internet.

Most of these networks have long since ceased to exist, and although UUCP still gets significant use in parts of the world where Internet infrastructure has not yet become well established, it subsequently transitioned to using Internet domain names, and pseudo-domains now largely survive as historical relics. One notable exception is the 2007 emergence of SWIFTNet Mail, which uses the swift pseudo-domain.[37]

The anonymity network Tor formerly used the top-level pseudo-domain .onion for onion services, which can only be reached with a Tor client because it uses the Tor onion routing protocol to reach the hidden service to protect the anonymity of users. However, the pseudo-domain became officially reserved in October 2015.[38] i2p provides a similar hidden pseudo-domain, .i2p,[39] and Namecoin uses the .bit pseudo-domain.[40]

Examples

[edit]
Examples of the over 1,500 TLDs
Example domain Type Sponsoring institution
.arpa Infrastructure Internet Architecture Board; restricted [41][a]
.blue Generic Identity Digital Limited; unrestricted[42]
.ovh Generic OVH SAS; run by AFNIC, unrestricted[43]
.name Restricted generic VeriSign Information Services, Inc.; unrestricted[44]
.ac Country-code Internet Computer Bureau; unrestricted[45]
.zw Country-code Postal and Telecommunications Regulatory Authority of Zimbabwe; run by TelOne Zimbabwe; unrestricted[46]
.aero Sponsored Société Internationale de Télécommunications Aéronautiques; unrestricted[47]
.ไทย Internationalized country-code THNIC[48]

See also

[edit]

Notes

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Top-level domain

View on Grokipedia
from Grokipedia
A top-level domain (TLD) is the highest level in the hierarchical (DNS), comprising the zone immediately subordinate to the root zone and typically appearing as the suffix after the final dot in a , such as "com" in or "jp" in example.jp. From a purely technical DNS perspective, TLDs hold no special operational status beyond their position in the , though they carry significant administrative and policy implications for and management. TLDs are categorized primarily into generic top-level domains (gTLDs), which include unrestricted options like .com and .org as well as sponsored or restricted ones like .gov and .edu, and country-code top-level domains (ccTLDs), which are two-letter codes assigned to countries or territories under , such as .us for the or .uk for the . The complete list of delegated TLDs is maintained in the by the (IANA), ensuring global consistency in name resolution. Introduced in the mid-1980s alongside the initial public deployment of the DNS, the original set of TLDs included six generic domains—.com, .edu, .gov, .mil, .net, and .org—followed by ccTLDs like .us, enabling the scalable organization of internet addresses beyond numeric IP addresses. Subsequent expansions, notably the 2000 introduction of seven new gTLDs such as .biz and .info, and the 2012 New gTLD Program that added hundreds more including brand-specific (.google) and community-oriented (.africa) extensions, have diversified the to over 1,500 active TLDs, fostering among registries while raising challenges in user recognition and cybersecurity risks from lesser-known extensions.

Fundamentals

Definition and Technical Role

A top-level domain (TLD) constitutes the highest level in the (DNS) immediately below the unnamed zone, representing the final segment of a (FQDN) following the last dot. For example, in the FQDN "www.", "" serves as the TLD. The (IANA) maintains the authoritative list of TLD delegations in the database, which records the administrative and technical contacts for each TLD. In the DNS resolution , TLDs fulfill a critical intermediary role by delegating authority from the root servers to second-level domains and beyond. Root name servers, when queried for an FQDN, respond with non-authoritative referrals (NS records) directing resolvers to the authoritative name servers for the relevant TLD. The TLD's name servers then handle subsequent queries for the , providing further referrals or the final IP address mappings via A or AAAA records. This layered delegation ensures efficient, distributed management of the global , preventing any single entity from bearing the full load of Internet-scale queries. TLD registries, operated under delegation from IANA, oversee the technical infrastructure for their zones, including zone file maintenance, WHOIS data publication, and enforcement of registration policies to maintain namespace integrity. This role extends to supporting DNS Security Extensions (DNSSEC) validation chains from the root, bolstering trust in resolution outcomes against tampering. Failure in TLD-level operations, such as misconfigured name servers, can disrupt access to all domains beneath it, underscoring their foundational position in Internet infrastructure stability.

Hierarchy in the DNS

The (DNS) organizes its as a hierarchical , with an unlabeled node at the apex, conventionally represented by a dot (.). This serves as the starting point for all resolutions, delegating downward through successively more specific labels. Top-level domains (TLDs) occupy the positions immediately below the , functioning as the primary zones into which the global is divided. Examples include generic TLDs such as .com and .org, and country-code TLDs such as .us and .uk. Each TLD represents a distinct of the , with its own set of authoritative name servers responsible for managing records within that zone. Delegation from the to TLDs occurs via NS resource records in the , which specify the IP addresses of the TLD's name servers. The Internet Assigned Numbers Authority (IANA) maintains this zone, compiling delegation data submitted by TLD operators and ensuring changes are propagated to server operators. This process integrates TLDs into the DNS by enabling recursive resolvers to query servers for referrals to TLD authoritative servers during name resolution. Beneath TLDs, the hierarchy extends to second-level domains (e.g., ) and further subdomains (e.g., sub.), with administrative control partitioned at "cuts" in the tree via additional NS records. This delegation model distributes management across registries, registrars, and domain owners, promoting scalability and fault tolerance in the distributed DNS database. Name servers at each level hold authoritative data for their zones and provide referrals for unresolved portions of queries, as defined in the DNS protocols.

Historical Development

Origins in ARPANET and Early TLDs (1960s-1980s)

The , funded by the U.S. Department of Defense's Advanced Research Projects Agency (), established its first network connection on October 29, 1969, between a host computer at the (UCLA) and the Stanford Research Institute (SRI), marking the initial operational phase of packet-switched networking that laid foundational infrastructure for domain naming concepts. Initially, ARPANET hosts were identified solely by numeric addresses, but by the early 1970s, alphabetic host names were introduced to facilitate human-readable identification, managed through a centrally maintained file called HOSTS.TXT distributed from SRI's Network (NIC). This flat naming system supported limited growth, with the file listing mappings for dozens of hosts by 1973, but it proved inadequate as ARPANET expanded to over 200 hosts by the late 1970s, causing delays in updates and synchronization issues across the network. To address these scalability limitations, Paul Mockapetris at the University of Southern California's Information Sciences Institute (ISI) developed the Domain Name System (DNS) as a hierarchical, distributed alternative to centralized host tables, proposing its architecture in RFC 882 (November 1983) and RFC 883 (November 1983), which defined domain names, resolvers, and name servers for decentralized resolution. DNS implementation began experimentally on ARPANET in 1984, transitioning from the temporary .arpa top-level domain—initially created for address mappings during the shift—to a structured namespace, with ISI operating early root name servers under Jon Postel's coordination as de facto manager of the Internet Assigned Numbers Authority (IANA). RFC 920 (October 1984), authored by Postel and Joyce Reynolds, formalized initial domain categories to organize the namespace, emphasizing separation by function and organization type to prevent namespace exhaustion. The first generic top-level domains (gTLDs) were introduced into the in January : .com for commercial entities, .edu for educational institutions, .gov for U.S. government bodies, for U.S. , .net for network operators, and .org for miscellaneous organizations, alongside country-code TLDs derived from ISO 3166. The inaugural .com registration occurred on March 15, , for symbolics.com, belonging to Symbolics Inc., a manufacturer, signifying the operational debut of commercial domain use on what would evolve into the public . These early TLDs were assigned sparingly, with fewer than 100 domains registered by the end of , reflecting ARPANET's primary research-oriented user base and the nascent stage of commercial internetworking before the 1983 ARPANET-MILNET split and broader TCP/IP adoption.

Formalization and ICANN Formation (1990s)

In the early 1990s, management of top-level domains (TLDs) transitioned from ad hoc practices rooted in ARPANET-era conventions to more structured guidelines under the (IANA), directed by at the University of Southern California's Information Sciences Institute. Postel personally maintained the file, delegating TLDs based on informal consultations and emerging standards, with the existing seven generic TLDs (.com, .edu, .gov, .mil, .net, .org, .int) and over 100 country-code TLDs (ccTLDs) forming the core structure. In March 1994, Postel published RFC 1591, which outlined principles for DNS structure and TLD delegation, emphasizing that TLD managers act as trustees responsible for operational stability, local policy alignment (especially for ccTLDs), and avoiding conflicts with national interests; this document served as the primary administrative framework without formal enforcement mechanisms. Concurrently, the (NSF) awarded a 1992 cooperative agreement to , Inc. (NSI) to operate the directory and handle registrations for .com, .org, and .net, initially at no cost; a 1995 amendment authorized NSI to charge $50 annually per domain, establishing a monopoly that fueled revenue but also complaints of high fees and poor service amid exploding demand. Rapid commercialization and internet expansion in the mid-1990s exacerbated issues like domain scarcity, trademark disputes, and NSI's exclusive control, prompting calls for additional TLDs and decentralized registration. In June 1996, Postel issued an Internet Draft proposing criteria for introducing up to 50 new generic TLDs to alleviate pressure on existing ones, which led to the formation of the International Ad Hoc Committee (IAHC) in November 1996. The IAHC's February 1997 Memorandum of Understanding (gTLD-MoU) recommended seven new gTLDs (.firm, .store, .web, .arts, .rec, .info, .nom) and a separated registry-registrar model with competitive registrars under a Policy Oversight Committee, aiming for global self-regulation; however, the proposal lacked U.S. government endorsement and faced opposition from NSI, trademark interests, and concerns over root stability, rendering it ineffective as few signatories implemented it. The U.S. Department of Commerce's July 2, 1997, Request for Comments asserted oversight to prevent uncoordinated changes, reflecting the government's historical funding role in NSF and DARPA contracts that had sustained IANA functions. The push for formalization culminated in U.S. policy directives prioritizing privatization while maintaining stability. On July 1, 1997, the Clinton administration's Framework for Global Electronic Commerce advocated shifting DNS coordination to private-sector leadership. The National Telecommunications and Information Administration (NTIA) issued its Green Paper on January 30, 1998, proposing a new U.S.-headquartered, not-for-profit corporation to assume IANA functions, including TLD policy development, root management, and promotion of competition, with principles of bottom-up consensus, global representation, and safeguards against capture by special interests. Following public comments, the June 5, 1998, White Paper endorsed this model, directing formation of the corporation by September 1998 and full U.S. government phase-out by September 30, 2000, while retaining temporary oversight via NSI's expiring NSF agreement. On September 30, 1998, the Internet Corporation for Assigned Names and Numbers (ICANN) was incorporated in California as this entity, with Postel's death on October 16, 1998, marking the end of informal IANA stewardship; ICANN was designated by NTIA in November 1998 to begin transitioning TLD oversight, introducing structured bylaws, stakeholder processes, and eventual new gTLD approvals. This framework addressed prior centralization risks by institutionalizing multi-stakeholder input, though early ICANN faced criticism for U.S. dominance and slow competition rollout.

Initial Expansions and Policy Shifts (2000s)

In November 2000, the Internet Corporation for Assigned Names and Numbers (ICANN) selected seven new generic top-level domains (gTLDs) for delegation following a competitive application process initiated in August of that year, marking the first deliberate expansion beyond the original set established in the 1980s. These included .aero (restricted to the aviation industry), .biz (for businesses), .coop (sponsored for cooperatives), .info (for informational sites), .museum (for museums), .name (for personal names), and .pro (for professionals). The selections emphasized a mix of sponsored TLDs, operated by entities representing specific communities to enforce eligibility rules, and unsponsored ones open to broader registration, aiming to alleviate namespace scarcity in legacy domains like .com without destabilizing the Domain Name System (DNS). ICANN's policy framework for this expansion, adopted by its Board on July 16, 2000, prioritized a "measured and responsible" approach, incorporating public consultations and evaluations of applicants' technical capabilities, business plans, and potential for competition. This reflected a causal shift from the prior de facto monopoly-like structure under U.S. government-linked oversight to fostering market-driven diversity, driven by post-1990s internet growth and demands from businesses facing domain hoarding in saturated TLDs. However, the process drew criticism for its opacity and favoritism toward established players, as evidenced by the Names Council's September 2000 warning against premature speculative pre-registrations, underscoring concerns over cybersquatting and enforcement challenges. A second limited round in 2003-2004 yielded additional delegations, including .jobs (October 2005, for employment services), .travel (October 2005, sponsored for travel industry), .mobi (September 2006, for mobile content), .tel (March 2007, for contact data), .asia (October 2007, regional sponsored TLD), and .cat (September 2006, for Catalan linguistic community), bringing the total new gTLDs to around 15 by decade's end. These introductions tested policies on registry contracts, such as phased launches to mitigate abuse and Uniform Domain-Name Dispute-Resolution Policy (UDRP) adaptations for trademark protections, revealing operational hurdles like low adoption rates for niche TLDs (e.g., .museum registrations remained under 1,000 by 2005) and debates over whether expansions diluted brand value in core domains. Broader policy evolutions included enhanced U.S. Department of Commerce oversight via agreements reaffirming ICANN's role in promoting competition while maintaining root zone stability, alongside initial explorations of internationalized domain names (IDNs) that laid groundwork for later 2010s implementations but faced delays due to technical encoding risks in the DNS protocol. By the late 2000s, these shifts signaled a transition toward scalable expansion models, though constrained by stakeholder consensus requirements and fears of fragmentation, with empirical data showing new TLDs capturing less than 5% of total registrations amid dominance by .com (over 70 million domains by 2009).

2012 New gTLD Program and Subsequent Rounds (2010s-2020s)

The New gTLD Program, initiated by , opened for applications on January 12, 2012, and closed on March 29, 2012, receiving 1,930 applications for new generic top-level domains. This initiative aimed to expand the space beyond the existing 22 gTLDs, allowing entities to apply for strings representing brands, industries, or communities, subject to evaluations for technical capability, operational plans, and competition concerns. conducted initial evaluations starting in 2013, including objection processes and auctions for contended strings, with the first delegations occurring in October 2013 for domains like .xn--mgbah1a3hjkrd ( variant) and progressing to Latin-script examples such as . expansions, though core new entries like .club and .guru followed in 2014. By the end of the 2010s, the program had delegated over 1,200 new gTLDs into the , with 1,241 reported as active by early statistics, representing a significant increase from the pre-2012 total of 22 gTLDs. These included brand-specific TLDs like .google and .apple, geographic ones such as .nyc, and generic terms like , which amassed millions of registrations, though adoption varied widely—some like .app gained traction for security-focused uses, while others saw limited uptake due to market fragmentation and registrar support issues. The process involved private auctions for over 50 contended strings, generating over $80 million in revenue for by 2016, but also faced delays from legal challenges and geographic name protections. In the 2020s, the 2012 program's delegations continued, reaching stabilization with ongoing monitoring for compliance, but ICANN shifted focus to subsequent procedures via a policy development process launched in 2016 to refine rules based on lessons from the first round, including enhanced support for internationalized domains and closed generics. The board approved recommendations in 2024 for a next application round tentatively set for April 2026, incorporating changes like streamlined evaluations and provisions for longer strings up to 63 characters, amid preparations for broader DNS expansion while addressing past criticisms of evaluation rigor and economic impacts on legacy TLDs. As of mid-2024, total delegated new gTLDs remained around 1,241, with no interim rounds conducted, reflecting deliberate pacing to ensure operational stability over rapid proliferation.

Classification of TLDs

Generic Top-Level Domains (gTLDs)

Generic top-level domains (gTLDs) constitute a primary category of top-level domains (TLDs) in the Domain Name System (DNS), distinguished from country code TLDs (ccTLDs) by their lack of association with specific geographic territories or sovereign entities. They are maintained by the Internet Assigned Numbers Authority (IANA) under the oversight of the Internet Corporation for Assigned Names and Numbers (ICANN), serving purposes ranging from general commercial and organizational use to specialized communities without national boundaries. gTLDs enable broad registration of second-level domains and are operated by contracted registry operators responsible for maintaining the zone files and handling registrations. The foundational gTLDs emerged in the 1980s as part of early DNS standardization efforts. ., delegated on March 15, 1985, was designated for commercial entities; . for non-commercial organizations; .net for internet infrastructure providers; . for post-secondary educational institutions; .gov for U.S. federal government entities; .mil for U.S. military branches; and .int for international organizations, with the latter delegated in 1988. These domains were initially unrestricted in policy except for implicit community expectations, though .gov and .mil have since imposed strict U.S. government eligibility. By the late 1990s, . had grown to dominate registrations, exceeding 4 million domains by 1998, driven by the 's commercialization. Expansions of gTLDs have occurred through ICANN-led application rounds to foster competition and innovation in the DNS namespace. The 2000 round added .biz (business), .info (information), .name (personal), and .pro (professionals), alongside sponsored variants like .aero (aviation) and .museum (museums), totaling seven new delegations. The landmark 2012 New gTLD Program opened applications from January 12 to April 20, 2012, receiving 1,930 bids and ultimately delegating 1,235 strings by 2021, including geographic (.africa), brand (.google, delegated May 2014), and generic (.app, .dev) extensions. This program generated over $500 million in application fees, funding ICANN operations and legal reviews to prevent conflicts like trademark infringements. As of March 2025, approximately 1,264 gTLDs are delegated in the , combining legacy and new extensions, out of roughly 1,590 total TLDs worldwide. Unrestricted gTLDs like .com (over 160 million registrations as of 2024) remain the most utilized, while newer ones such as .online and .shop have captured niche markets, with new gTLDs collectively holding about 10% of global domain registrations. 's ongoing policy development, including a planned 2026 application round, aims to further diversify gTLDs, though challenges like market saturation and cybersecurity concerns persist. gTLD requires demonstrating operational, technical, and , with IANA performing final root zone changes upon ICANN approval.

Country Code Top-Level Domains (ccTLDs)

Country code top-level domains (ccTLDs) are two-letter top-level domains in the Domain Name System (DNS) specifically allocated to represent countries, sovereign states, dependencies, and certain geographical or political areas. They are defined using the alpha-2 codes from the ISO 3166-1 standard, which assigns unique two-letter identifiers to over 240 countries and territories. Examples include .us for the United States, .de for Germany, and .jp for Japan. The Internet Assigned Numbers Authority (IANA) oversees their inclusion in the DNS root zone, maintaining a database of delegation records that details sponsoring organizations and name servers for each active ccTLD. Eligibility for a ccTLD is tied directly to codes, ensuring international recognition and stability; however, delegation is not automatic and requires formal processes. IANA delegates or redelegates ccTLDs only upon verified requests demonstrating significant local interest, technical stability, and operational capacity from the relevant national administration or community. This involves assessments of policy frameworks, mechanisms, and commitments to non-discriminatory practices, as outlined in guidelines like ICP-1. Redelegations, such as transfers to new managers, follow similar scrutiny to prevent disruptions, with IANA inserting root zone records only after validation. Management of individual ccTLDs is delegated to local or national registry operators, who set registration policies, pricing, and eligibility rules tailored to their jurisdiction's needs. Many impose geographic restrictions, requiring registrants to demonstrate ties to the country (e.g., residency or business presence), to preserve national sovereignty and prevent . Others, however, permit unrestricted global registrations, leading to widespread generic or commercial use beyond their ISO-designated territories. Notable examples include (), adopted by companies for its association with "input/output"; (), marketed for video and broadcasting content; and (), leveraged for branding. These practices have generated revenue for smaller nations while raising questions about original intent versus market-driven evolution. By the second quarter of 2025, ccTLDs supported 143.4 million registered domain names worldwide, accounting for roughly 39% of total global registrations and reflecting steady growth driven by both local adoption and international appeal in select codes. Despite their national focus, ccTLDs contribute to DNS diversity, with operators often collaborating through bodies like the Country Code Names Supporting Organization (ccNSO) under ICANN for policy coordination. Sponsored top-level domains (sTLDs) constitute a of generic TLDs operated under the oversight of a that represents and advocates for a narrowly defined . The sponsor formulates and implements policies detailed in a formal , which specifies the TLD's purpose, eligibility criteria for registrants, and operational guidelines to ensure benefits accrue primarily to the intended stakeholders rather than the general public. This structure delegates policy authority to the sponsor, distinguishing sTLDs from unsponsored gTLDs like .com, and was designed to foster specialized namespaces amid ICANN's initial efforts to expand the TLD pool beyond legacy domains in the early . The first wave of sTLDs emerged from ICANN's 2000-2001 application process, yielding delegations such as .museum to the Museum Domain Management Association on October 17, 2001, restricted to verified museums and related institutions; .aero to Société Internationale de Télécommunications Aéronautiques (SITA) on March 18, 2002, for aviation and aerospace entities requiring proof of legitimate interest; and .coop to DotCooperation LLC on January 30, 2002, limited to cooperatives demonstrating compliance with cooperative principles. Subsequent sTLDs include .jobs, sponsored by the Society for Human Resource Management and delegated in May 2005 for employment-related services, though its charter restrictions were relaxed by ICANN decision in 2013 to allow broader professional use; and .post, delegated to the Universal Postal Union on August 2, 2012, exclusively for postal sector operators. These domains enforce restrictions through verification processes, such as nexus requirements or endorsements, to mitigate cybersquatting and preserve community relevance. Restricted TLDs encompass domains with stringent registration criteria tied to specific qualifications, often governmental or professional mandates, which may overlap with sponsored models but emphasize operational control by authoritative bodies rather than community charters. Prominent examples include .gov, delegated since 1997 and managed by the U.S. since 2017, confined to U.S. federal, state, local, and tribal government entities to secure official communications; .mil, operated by the U.S. Department of Defense since 1985, accessible solely to military components; and .edu, administered by since October 29, 2001, eligible only for accredited U.S. postsecondary degree-granting institutions meeting federal criteria. Other restricted cases, like the unsponsored .pro introduced in 2002 for licensed professionals (e.g., lawyers, physicians) via credential verification, illustrate how such TLDs prioritize authenticated use to uphold trust and prevent dilution, though some have evolved toward partial openness under oversight. These mechanisms reflect causal priorities of namespace stability and targeted utility, enforced via contractual obligations with registry operators.

Internationalized TLDs

Technical Implementation of IDNs

Internationalized domain names (IDNs) are technically implemented through the Internationalizing Domain Names in Applications (IDNA) protocol, which enables the use of characters in domain labels while maintaining compatibility with the ASCII-based (DNS). The DNS protocol itself remains unchanged, operating solely on ASCII strings, so IDNs are encoded into an ASCII-compatible format known as before storage, delegation, and resolution. This encoding occurs at the , where software converts user-input domain names into representations (prefixed with "xn--") for DNS queries, and reverses the process for display upon receiving responses. The core encoding mechanism relies on , defined in RFC 3492, which maps Unicode code points to a of ASCII characters using a bootstring that biases shorter encodings toward basic Latin letters (a-z, , and ). For a given IDN label, the process begins with normalization (typically to Normalization Form KC), followed by validation against IDNA rules to exclude disallowed or contextually invalid characters—such as certain combining marks or right-to-left script overrides that could lead to visual spoofing. Valid labels are then encoded: the string prepends "xn--" to the encoded non-ASCII portion, ensuring the full domain (e.g., "café.example" becomes "xn--caf-dma.example") is DNS-resolvable as an A-label. In the DNS hierarchy, IDN top-level domains (TLDs) are delegated in the root zone as strings, with zone files and authoritative servers handling only these ASCII forms. The IDNA framework has evolved from the 2003 specification (RFC 3490) to the 2008 version (RFCs 5890–5894), with the latter decoupling string preparation and mapping from core validation to better align with standards and reduce legacy mappings that could introduce ambiguities. IDNA2008 introduces categories like PVALID (permitted characters), DISALLOWED (prohibited ones), and CONTEXTJ (requiring contextual checks, e.g., for emoji-like separators), processed via a mapping table and Bidi rule enforcement to prevent homographic attacks. Implementations must handle these steps deterministically; for instance, libraries like Libidn provide open-source compliance with both IDNA variants, though registries increasingly adopt IDNA2008 for new delegations to mitigate validation inconsistencies present in the earlier profile. DNS resolvers and clients, such as those in modern browsers, perform bidirectional conversion transparently, but mismatches in IDNA version support across systems can result in resolution failures for legacy IDNA2003 names.

IDN gTLDs and ccTLDs

Internationalized country code top-level domains (IDN ccTLDs) enable countries and territories to delegate top-level domains in their native scripts rather than relying solely on Latin-script two-letter codes assigned under ISO 3166-1. The Internet Corporation for Assigned Names and Numbers (ICANN) established a fast track process for IDN ccTLDs in October 2009, allowing eligible governments and administrations to submit applications starting November 16, 2009. The initial string evaluation phase assessed linguistic and technical criteria, such as script compatibility and variant management, to prevent confusion with existing domains. The first three IDN ccTLDs—.مصر for Egypt, .السعودية for Saudi Arabia, and .امارات for the United Arab Emirates—were delegated into the DNS root zone on May 5, 2010, marking the inaugural non-Latin-script top-level domains. Subsequent delegations followed through the standard ccTLD delegation process, incorporating root zone management by the Internet Assigned Numbers Authority (IANA). By June 2024, 61 IDN ccTLDs had been delegated, representing strings from 43 countries and territories across scripts including Arabic, Bengali, Chinese, Cyrillic, Greek, Hebrew, and Thai. These include prominent examples such as .рф (Cyrillic for Russia, delegated 2010), .中国 and .中國 (Simplified and Traditional Chinese variants for China, delegated 2010), and .台灣 (Traditional Chinese for Taiwan, delegated 2010). Some countries operate synchronized IDN ccTLDs, where multiple variant strings (e.g., .中国 and .中國) are delegated to the same manager to ensure stability and prevent fragmentation, as outlined in ICANN's variant TLD guidelines. Internationalized generic top-level domains (IDN gTLDs) extend this capability to non-country-specific domains, allowing applications for generic strings in non-Latin scripts as part of ICANN's new gTLD expansion program. Applicants could submit IDN gTLD proposals during the 2012 application window, subject to the same evaluation processes as ASCII gTLDs, including community endorsements, technical feasibility, and IDN-specific variant handling. The first IDN gTLDs were delegated in 2013, following root zone stability testing and policy approvals for variant delegations. As of June 2024, approximately 90 IDN gTLDs were delegated, contributing to a total of 151 IDN top-level domains across 37 languages and 23 scripts. Examples include .在线 (Chinese for "online"), .网址 (Chinese for "website"), and .ไทย (Thai script), which underwent ICANN's string contention resolution and were integrated into the root zone under registry agreements emphasizing DNSSEC support and abuse mitigation. Unlike IDN ccTLDs, which are government-controlled, IDN gTLDs are operated by private or sponsored entities, with delegations requiring demonstration of operational capacity and adherence to ICANN's multi-stakeholder policies. Ongoing challenges in variant management, such as allocating confusables across scripts, have led to phased implementations, with ICANN recommending single-registrar models for certain high-risk strings to maintain global interoperability.

Adoption and Challenges

As of June 2024, 151 internationalized top-level domains (IDN TLDs) have been delegated in the DNS root zone, comprising 61 IDN country code TLDs (ccTLDs) and 90 IDN generic TLDs (gTLDs), spanning 23 scripts and 37 languages. This represents a modest expansion from prior years, with the IDN ccTLD Fast Track Process enabling initial delegations starting in 2010 for non-controversial strings associated with ISO 3166-1 country codes. Adoption at the top level has been uneven, driven by regional demands for native-script representations, such as Cyrillic for Russian-speaking territories and Chinese characters for East Asian markets, though global delegation growth has slowed amid broader TLD proliferation exceeding 1,400 total entries. Registrations under IDN TLDs exhibit limited penetration relative to ASCII-based equivalents, with second-level IDN registrations across all gTLDs totaling 1.467 million as of March 2024—a 3.36% decline from December 2022 levels. IDN domains constitute less than 1% of the approximately 362 million total domain registrations worldwide as of early 2024. Notable successes include the Russian .рф ccTLD, which amassed over 900,000 registrations shortly after its 2010 delegation and remains a high-usage example for Cyrillic scripts, and Chinese IDN TLDs like .中国, which exceeded 2 million registrations at launch, reflecting strong domestic uptake in script-dominant markets. Chinese scripts dominate second-level IDN registrations under gTLDs at 48.74%, underscoring concentrated adoption in Asia over broader global dispersion. Technical challenges persist in IDN TLD implementation, including inconsistent handling of Punycode-encoded strings (e.g., xn--*) across browsers and software, which can lead to display errors or fallback to ASCII transliterations, hindering seamless user experience. Security vulnerabilities, particularly homograph attacks, pose significant barriers, where visually similar characters from different scripts (e.g., Cyrillic 'а' mimicking Latin 'a') enable phishing by impersonating legitimate domains, as documented in analyses of IDN deployment risks. These issues have prompted browser-level defenses and restrictions on certain script mixtures, but incomplete mitigation contributes to registrar and user hesitancy. Market and policy factors further impede adoption, including entrenched reliance on Latin-script domains for international compatibility, insufficient label generation rules (LGRs) for underrepresented scripts requiring cross-registry collaboration, and varying national policies on IDN ccTLD . Despite ICANN's ongoing IDN and variant efforts, such as the EPDP for IDN gTLDs, declining registration trends signal that apprehensions and legacy outweigh localization benefits for many users outside script-primary regions.

Special and Reserved TLDs

Infrastructure and Operational TLDs

The top-level domain (TLD) functions as the designated infrastructure TLD within the (DNS), reserved exclusively for operationally critical infrastructure purposes, such as mapping network addresses and parameters essential to DNS resolution and . Administered by the (IANA) under the sponsorship of the (IAB), .arpa ensures the stability of core DNS functions by supporting identifier spaces that underpin global network operations, without allowance for general-purpose registrations. Delegation changes are coordinated manually through IANA, adhering to strict guidelines that prohibit commercial or branding uses. Originally established on January 1, 1985, . originated as part of the early DNS hierarchy to facilitate the ARPANET's transition to TCP/IP and to enable delegated authority for network addressing. Following the completion of this migration, the domain was phased out in the early 1990s but was redelegated in 2000 to address ongoing needs for infrastructure support, formalized through RFC 3172, which outlines management requirements including delegation procedures, operational stability, and coordination with relevant standards bodies like the (IETF). This redelegation emphasized .arpa's in reverse DNS lookups, preventing fragmentation of essential mappings across zones. The domain DNSSEC-signed since 2010 to enhance security for its critical subzones. Prominent subdomains under .arpa include in-addr.arpa, which provides reverse mapping for IPv4 addresses by encoding dotted-decimal notations in domain labels, as specified in RFC 1035 (1987); and ip6.arpa, dedicated to IPv6 reverse mappings using nibble-encoded hexadecimal labels, delegated per RFC 3152 (2001). Additional operational subdomains encompass home.arpa for non-unique, local residential networking to avoid conflicts with global DNS (RFC 8375, 2018); e164.arpa for mapping international telephone numbers to URIs via the ENUM protocol; uri.arpa and iris.arpa for resolving uniform resource identifiers and internationalized resource identifiers, respectively; and reserved segments like 8.e.f.ip6.arpa for documentation and testing of IPv6 well-known prefixes. These subdomains are delegated to regional Internet registries or standards-defined operators, ensuring precise control over infrastructure-critical resolutions without public registration. As the sole infrastructure TLD, .arpa underscores the DNS's foundational reliance on specialized zones for operational integrity, distinct from user-facing or generic TLDs, with IANA maintaining oversight to mitigate risks like delegation errors that could disrupt global reverse lookups.

Reserved, Test, and Example TLDs

The (IETF) reserved four top-level domains (TLDs) in RFC 2606, published on June 4, 1999, to address issues arising from the use of top-level DNS names in documentation, testing, and non-production environments, thereby preventing unintended interactions with production DNS infrastructure. These reservations ensure that names under .test, .example, .invalid, and .localhost do not trigger DNS queries to the global root servers or cause conflicts in real-world deployments. RFC 6761, published on February 25, 2013, formalized the concept of special-use domain names, incorporating these TLDs into a broader framework for domains reserved for technical purposes without requiring delegation in the DNS root zone. The .test TLD is designated for testing current or new DNS-related code and applications, allowing developers to simulate DNS environments without risking queries to authoritative servers. Names under .test, such as example.test, are recommended for local experimentation but must not be used in production to avoid namespace pollution. Similarly, .example serves as a placeholder in technical documentation, specifications, and sample configurations, enabling clear illustration of DNS usage without implying real-world resolvability. For instance, RFCs frequently employ domains like www.example.com to demonstrate concepts without referencing actual sites. The .invalid TLD denotes syntactically domain names, useful for error handling in software that parses or generates DNS labels, ensuring such names are immediately recognizable as erroneous rather than queryable. It prevents applications from attempting resolution on malformed inputs. Finally, .localhost maps to the address (127.0.0.1 in IPv4 or ::1 in ), a convention statically defined in most host implementations for referencing the local machine without external network dependency; it is reserved to maintain this local-only semantics and block unintended remote resolutions. These reservations are enforced through guidelines in RFC 6761, which advises DNS resolvers and authoritative servers to handle queries for these domains locally or reject them without forwarding, reducing load on the global DNS infrastructure and enhancing security by mitigating risks like attacks. The IANA maintains a registry of special-use domains, confirming these TLDs' status without assigning operators or delegation. Compliance is voluntary but widely adopted in standards-compliant software, as evidenced by their integration into major DNS implementations since the RFCs' issuance.

Historical, Retired, and Pseudo-TLDs

Historical top-level domains encompass the earliest delegations in the (DNS), implemented in 1984 with the first TLDs entering the root zone in 1985. Initially, served purposes, followed by the generic TLDs , , , , , and , with the first second-level domain, , registered on March 15, 1985. These formed the foundation of the global namespace before widespread ccTLD adoption based on codes. Early experimental or organization-specific delegations, such as .nato for the North Atlantic Treaty Organization, were added around 1985–1990 but saw limited use due to the nascent . Retired TLDs are those removed from the DNS root zone, primarily ccTLDs rendered ineligible by geopolitical dissolution or code withdrawal under , as managed by IANA. The retirement process involves notifying the TLD manager, facilitating an orderly shutdown to protect registrants, and defaulting to a five-year before removal, though shorter timelines apply if no viable successor exists. Notable examples include: Other historical cases, like Australia's interim .oz before .au's dominance in 1986, faded without formal root removal. Retirements prioritize stability, often grandfathering domains during transitions, but underscore the DNS's sensitivity to real-world political changes. Pseudo-TLDs denote unofficial TLD strings employed in private networks, intranets, or alternative resolution protocols outside the global DNS hierarchy, risking future collisions if later delegated officially. Common examples include .internal, .private, and .local (the latter standardized for Multicast DNS under RFC 6762 but historically ad-hoc). To address proliferation and interoperability issues, RFC 9476 (2023) reserves .alt as a special-use TLD for non-DNS contexts like private naming or experimental systems, advising developers to migrate pseudo-TLD usages thereunder rather than inventing new ones, though no mandate enforces this. This guidance complements reserved special-use domains (e.g., .test, .example per RFC 6761) by targeting unofficial practices that bypass IANA delegation. Adoption of .alt remains optional, but it promotes causal avoidance of namespace conflicts in distributed systems.

Governance and Administration

Roles of IANA and ICANN

The serves as the operational coordinator for the root zone, which includes assigning and overseeing operators for top-level domains (TLDs) such as .com and country-code TLDs like .uk. This entails maintaining the authoritative root zone database, processing delegation and redelegation requests for TLDs, and ensuring the accuracy of records in the root zone to activate new domains in the global DNS. IANA's functions in this area emphasize technical implementation over policy, verifying requests from TLD sponsors or governments before updating the root files distributed to root server operators. In contrast, the Internet Corporation for Assigned Names and Numbers (ICANN) holds primary responsibility for policy development and oversight of the TLD ecosystem, including the introduction of new generic TLDs (gTLDs) through application rounds that promote market competition while safeguarding DNS stability. ICANN contracts with TLD registries—single entities authorized to manage all second-level domains under a given TLD—and enforces operational standards, dispute resolution mechanisms, and contractual obligations to maintain the integrity of the domain hierarchy. Established in 1998 to transition DNS management from U.S. government oversight, ICANN operates a multi-stakeholder model involving governments, businesses, and technical experts to formulate TLD policies, distinct from IANA's execution-focused role. The operational relationship between IANA and is contractual: since 1998, ICANN has performed IANA functions for domain names under agreements, with IANA's TLD-specific tasks—such as root zone changes—implemented at ICANN's direction following approval. In 2016, these functions were separated into Public Technical Identifiers (PTI), an ICANN affiliate, to enhance operational independence while preserving ICANN's authority; PTI now directly handles IANA's root zone maintenance, but ICANN retains ultimate accountability through oversight and funding mechanisms. This division ensures technical reliability—critical for preventing DNS disruptions—while allowing ICANN to address evolving needs, such as expanding the TLD namespace beyond the original seven gTLDs delegated in 1985.

TLD Delegation and Root Zone Management

The delegation of a top-level domain (TLD) entails the addition of its nameserver (NS) records and associated delegations to the , rendering it resolvable worldwide. The (IANA), operated by the (ICANN), maintains the root zone database, which lists all active TLDs, including generic TLDs (gTLDs) like .com and country-code TLDs (ccTLDs) like .us. As of March 2025, this database encompasses 1,443 TLDs. For ccTLDs, the delegation or redelegation begins with a formal request to IANA from the relevant , , or designated manager, accompanied by demonstrating administrative, technical, and operational competence. IANA evaluates the request against criteria such as significant support, stability, and adherence to global policies before approving changes. gTLD delegations, by contrast, follow 's competitive application and evaluation rounds; upon selection, issues a token to IANA, authorizing the root zone entry after technical validation. Root zone management comprises the editing, cryptographic signing for DNSSEC, publication, and distribution of the root zone file, executed no less than daily to maintain DNS integrity. serves as the Root Zone Maintainer under a service agreement with renewed in October 2024, handling file generation, key signing ceremonies, and submission processing via ICANN's systems. Following the IANA stewardship transition on October 1, 2016, assumed full responsibility for these functions through its multi-stakeholder framework, eliminating prior U.S. Department of Commerce oversight. In May 2022, deployed the Root Zone Management System (RZMS), an automated platform for secure change coordination between IANA, , and root server operators.

Policy-Making and Multi-Stakeholder Model

ICANN's policy-making for top-level domains (TLDs) operates within a multi-stakeholder framework designed to incorporate input from diverse global participants, including private sector entities, civil society, technical experts, and governments, through a bottom-up consensus process rather than centralized directive. For generic TLDs (gTLDs), the Generic Names Supporting Organization (GNSO) leads policy development via Policy Development Processes (PDPs), which begin with an issues report, followed by formation of working groups, extensive public consultations, and iterative drafting to achieve community consensus before GNSO Council recommendation to the ICANN Board. This approach produced the 2008 GNSO recommendations enabling the 2012 new gTLD expansion, which introduced over 1,200 new TLDs by emphasizing competition and choice in domain naming. Country code TLDs (ccTLDs) follow a parallel structure under the Country Code Names Supporting Organization (ccNSO), focusing on operator-led policies with advisory input, while delegation and redelegation decisions involve the (GAC) for public policy considerations, ensuring alignment with national interests without overriding technical standards. The multi-stakeholder model integrates advisory bodies like the At-Large Advisory Committee (ALAC) for end-user perspectives and the for governmental advice, with public comment periods mandated at key stages to mitigate capture by any single interest group, though processes can extend over years, as seen in the ongoing PDP for subsequent gTLD procedures initiated in 2019. Proponents argue the model has sustained Internet stability and innovation by avoiding unilateral state control, enabling TLD policies responsive to technical and market evolution since ICANN's inception in 1998. Critics, including some governance scholars, contend it risks inefficiency, special-interest dominance—particularly by domain registrars and large corporations—and insufficient accountability to non-participating users, potentially undermining legitimacy amid growing geopolitical pressures for intergovernmental alternatives. Despite these debates, empirical outcomes like the successful delegation of IDN ccTLDs in 2010 via multi-stakeholder coordination demonstrate the model's capacity for inclusive, evidence-based decisions balancing global interoperability with localized needs.

Controversies and Criticisms

Debates Over TLD Expansion

The introduction of the New gTLD Program by ICANN in 2012, which received 1,930 applications for new top-level domains from applicants in 60 countries and territories, marked the largest expansion of the domain name space since the internet's early days. This initiative aimed to enhance competition and innovation by allowing virtually any string as a gTLD, subject to evaluation criteria, but it immediately ignited debates over its necessity, risks, and long-term impacts on internet stability. Proponents argued that expansion would alleviate scarcity in legacy TLDs like .com, foster branded namespaces, and enable more precise online expression, potentially generating revenue for operators through registration fees. However, critics, including brand owners and governments, contended that the program's flawed assumptions and high barriers—such as the $185,000 application fee per TLD—would yield minimal benefits while amplifying vulnerabilities. Arguments in favor of TLD expansion emphasized economic and functional advantages. ICANN projected that new gTLDs would promote competition, reduce monopoly power held by established registries, and allow entities like corporations or communities to curate tailored digital spaces, such as .brand or industry-specific extensions. For instance, operators could exert greater control over content and monetization, potentially lowering costs for end-users over time through market dynamics. Supporters, including some tech advocates, viewed the expansion as a natural evolution of the DNS to accommodate global growth, citing the program's multi-stakeholder review process as a safeguard against abuse. Yet, empirical outcomes have been mixed; while over 1,200 gTLDs were delegated by 2016, many achieved low registration volumes, suggesting limited consumer demand and questioning the scale of purported innovations. Opposition focused on tangible risks to security, trust, and operational integrity. The Association of National Advertisers outlined ten key concerns, including unsubstantiated justifications for expansion, excessive costs harming smaller entities, and heightened threats from phishing, spoofing, and cybersquatting enabled by a fragmented namespace. Governments echoed these worries; in 2025 testimony, U.S. officials opposed broad further expansion, citing evidence that proliferating TLDs facilitates spam and DNS abuse, complicating mitigation efforts for registrars and users. Academic analyses reinforced this, arguing that the influx dilutes trademark protections, invites defensive registrations by brands (costing millions), and erodes user confidence without commensurate gains, as legacy TLDs continue dominating traffic. Additional critiques highlighted ICANN's accountability gaps, with objection processes burdened by fees up to $5,000 or more per dispute, favoring deep-pocketed applicants over public interest. Ongoing debates, particularly ahead of potential next-round applications, center on cost-benefit trade-offs. ICANN's 2024 analysis acknowledged high operational costs for future rounds, including enhanced abuse prevention, but projected benefits like ecosystem diversity; however, stakeholders remain divided, with brand protection groups advocating restraints to prioritize stability over experimentation. Controversies over "closed generic" gTLDs—where operators like Amazon sought exclusive control over terms like .buy—further illustrate tensions, as critics argued such allocations privatize public namespaces, contravening open internet principles without proven societal value. Ultimately, while expansion has not collapsed the DNS, its critics substantiate claims of net harm through elevated abuse metrics and underutilization, underscoring causal links between namespace proliferation and heightened defensive burdens on the ecosystem.

Specific Disputes and Rejections

One prominent dispute involved Amazon's application for the .amazon generic top-level domain (gTLD), submitted in 2012 as part of ICANN's new gTLD program. South American governments, including Brazil and Peru, objected via the Governmental Advisory Committee (GAC), arguing that "amazon" holds geographic and cultural significance referring to the Amazon River basin and indigenous communities, potentially conflicting with public interest and national sovereignty. ICANN's board rejected the application in March 2013 following GAC advice, prompting Amazon to appeal through an independent review process, which in 2017 criticized ICANN for undue deference to GAC without sufficient justification. Despite the initial rejection, the board approved delegation in May 2019 after prolonged negotiations, though the decision drew criticism from objecting nations for prioritizing commercial interests over geographic protections. Similarly, Patagonia Inc.'s bid for .patagonia, a brand-specific gTLD applied for in 2012, faced GAC objections from Argentina and Chile, which asserted the term's reference to a shared geographic region spanning their territories warranted rejection to avoid misleading associations or sovereignty encroachments. The applicant withdrew the application in July 2013 after receiving formal GAC warnings, illustrating how governmental input can effectively block bids for strings with regional connotations, even absent explicit treaties. This case highlighted tensions between corporate branding rights and international claims to culturally significant names, with no delegation occurring. Technical and operational concerns have also led to outright rejections of certain applications from the 2012 round. For instance, proposals for .corp, .mail, and .home were denied due to risks of namespace collisions with widely used internal domain strings in private networks, which could disrupt email routing and DNS stability without global coordination. ICANN planned to delete 19 such failed applications in October 2025, including those withdrawn for non-payment of fees or unresolved contention, underscoring the program's stringent evaluation criteria beyond objections. Applications for strings consisting solely of numbers were automatically rejected to prevent confusion with existing infrastructure. String confusion objections have resolved other disputes by rejecting applications deemed too similar to existing TLDs or ccTLDs. In one determination, Dish DBS Corporation's objection against Verisign's .dtv application succeeded on grounds of potential user error between .dtv and the existing .tv ccTLD, leading to the challenger's application being prioritized while the other faced rejection risks in contention resolution. Legal rights objections, handled by providers like WIPO, have similarly invalidated bids infringing trademarks, such as multiple challenges to .vip where panels favored established rights holders, resulting in applicant withdrawals or denials. These mechanisms ensure competitive or conflicting applications often end in rejection for all but the prevailing party, frequently via private auctions where losing bids are discarded.

Security, Abuse, and Economic Impacts

The proliferation of generic top-level domains (gTLDs) has introduced security vulnerabilities, including domain collisions where internal networks inadvertently resolve public TLDs, potentially exposing private resources to external threats; this issue has intensified since the 2012 gTLD expansion, as organizations often use unregistered strings as internal TLDs without anticipating their delegation. Newer TLDs mimicking file extensions, such as Google's .zip launched in 2023, heighten risks by facilitating phishing and malware distribution, as users may confuse them with downloadable archives, leading to unintended DNS queries and exploitation. Domain Name System Security Extensions (DNSSEC), which cryptographically signs DNS records to prevent spoofing and cache poisoning, have been deployed at most TLD levels since the root zone signing in 2010, yet global validation adoption remains low due to operational complexities, lack of universal resolver support, and minimal end-user incentives, leaving many deployments ineffective against attacks. Abuse of TLDs, encompassing phishing, spam, and malware hosting, disproportionately affects new gTLDs, which exhibit abuse rates up to 32 times higher than legacy TLDs like .com and .net, driven by low registration costs (often under $2 annually) and lax oversight that enable rapid domain proliferation for malicious purposes. In 2024, new gTLDs accounted for 42% of detected phishing domains despite comprising a smaller share of total registrations, with specific TLDs like .top experiencing a 50% surge in abuse listings on blacklists such as Spamhaus. ICANN's Domain Abuse Activity Reporting (DAAR) system reported a median phishing abuse rate of approximately 0.3% across gTLDs in early 2020, though outliers like certain low-price TLDs exceed this, contributing to 51% of abusive new gTLD registrations; country-code TLDs (ccTLDs) generally show lower rates, around 0.05% in EU-operated ones. Economically, the global domain name market reached $2.40 billion in revenue in 2024, projected to grow to $3.57 billion by 2033 at a 4.5% CAGR, fueled by gTLD expansion that increased supply and diversified offerings, yet this has depressed average prices and amplified abuse-related costs for mitigation, enforcement, and lost consumer trust. TLD operators and registrars face heightened expenses from contractual obligations to combat abuse, as mandated by ICANN amendments in April 2024, including backend monitoring and rapid takedown processes, which strain smaller entities and indirectly raise barriers for legitimate users. While premium domain sales generate significant aftermarket value—exemplified by high-profile auctions—the erosion of TLD reputation due to abuse reduces overall ecosystem reliability, potentially diminishing long-term investment in digital branding and increasing cybersecurity expenditures for businesses verifying domain legitimacy.

Future Directions

Planned gTLD Application Rounds

ICANN has announced plans for the next round of generic top-level domain (gTLD) applications, known as the New gTLD Program: Next Round, to expand the Domain Name System namespace beyond the delegations from the 2012 round. The application submission period is projected to open in April 2026 and last 12–15 weeks, contingent on the completion of ongoing policy implementation work. This timeline reflects steady progress, including the publication of a draft Applicant Guidebook (AGB) for public comment on May 30, 2025, which outlines application requirements, evaluation processes, and operational guidelines. Key preparations include updates to the AGB incorporating feedback from prior rounds, such as enhanced protections against abusive registrations and streamlined evaluation criteria. The expected initial evaluation fee per application is USD $227,000, covering technical, operational, and financial stability assessments, though final approval of fees remains pending. Registry Service Providers (RSPs) must undergo pre-evaluation, with over 50 providers accredited or in process as of mid-2025 to support applicants. An Applicant Support Program aims to reduce financial barriers for eligible applicants from underrepresented regions or communities, building on lessons from the 2012 round's limited uptake in such areas. As of October 2025, ICANN continues implementation of the Governmental Advisory Committee (GAC) and other stakeholder recommendations, including refined objection mechanisms and geographic name protections, to mitigate issues like string contention observed previously. Auctions for contended strings will follow standard contention resolution policies, with recent requests for information issued to refine auction processes. The round prioritizes open-ended string applications without predefined categories, allowing broader innovation while maintaining root zone stability managed by IANA. Delays could arise from unresolved policy outputs, but current milestones indicate alignment with the Q2 2026 target.

Emerging Technologies and Proposals

Decentralized domain name systems, leveraging blockchain technology, represent a primary emerging proposal challenging the centralized DNS model managed by ICANN. These systems aim to enable user-owned, censorship-resistant domain registrations stored on distributed ledgers, allowing names to function as cryptographic identifiers for wallets, websites, and decentralized applications. Unlike traditional TLDs delegated through the DNS root zone, blockchain-based alternatives operate on independent blockchains, resolving names via smart contracts rather than recursive DNS queries. Prominent examples include the Ethereum Name Service (ENS), which uses the .eth TLD on the Ethereum blockchain, enabling bidirectional resolution between blockchain addresses and human-readable names since its mainnet launch in 2017, with over 2 million registrations by mid-2025 driven by Web3 adoption. Unstoppable Domains offers onchain TLDs such as .crypto, .nft, and .wallet, which integrate with multiple blockchains for identity and payment functions, reporting more than 3 million domains minted by early 2025. Handshake, a permissionless root zone protocol, allows users to bid on TLDs via proof-of-work auctions, fostering a market of over 100,000 registered names by 2025, though adoption remains niche due to reliance on browser extensions or gateways for traditional web access. These technologies propose replacing or augmenting ICANN's hierarchical delegation with peer-to-peer consensus mechanisms, potentially reducing reliance on trusted intermediaries and enabling programmable domains tied to NFTs for tradability. Proponents argue this enhances security through immutability and user sovereignty, as domains cannot be seized by central authorities, addressing vulnerabilities like government-mandated takedowns observed in DNS. However, interoperability challenges persist, including name collisions with existing TLDs—such as blockchain systems inadvertently using strings like .com—and limited native support in major browsers, requiring plugins that fragment user experience. ICANN has acknowledged these developments in 2024 publications, outlining coordination needs for "alt-TLDs" not in the global DNS, while warning of risks like fragmented namespace stability. Within the ICANN framework, proposals for hybrid TLDs incorporating blockchain elements have surfaced, such as applications for .blockchain as a generic TLD to bridge traditional DNS with distributed ledgers, anticipated for evaluation in the 2026 delegation following the 2025 application window. Additionally, custom Web3 TLDs on platforms like Decentraweb and Freename allow communities to launch branded extensions with emoji support and subdomain monetization, emphasizing digital sovereignty over ICANN's policy-driven model. These innovations, while innovative, face scrutiny for scalability issues—blockchain resolution times exceeding DNS's sub-second latency—and potential for abuse in unregulated spaces, prompting calls for standardized interfaces to avoid ecosystem silos. Empirical data from 2025 shows blockchain domains comprising under 1% of total registrations (368 million globally), indicating marginal but growing influence amid Web3's expansion.

References

  1. https://www.iana.org/go/rfc9499
  2. https://newgtldprogram.icann.org/en/about
  3. https://www.icann.org/en/contracted-parties/registry-operators/resources/list-of-top-level-domains
  4. https://www.icann.org/resources/pages/newgtlds-history-2023-04-05-en
  5. https://newgtlds.icann.org/en/about/program
  6. https://efficientip.com/glossary/top-level-domain/
  7. https://www.cloudflare.com/learning/dns/top-level-domain/
  8. https://www.iana.org/domains/root/db
  9. https://www.cloudflare.com/learning/dns/what-is-dns/
  10. https://www.iana.org/domains
  11. https://datatracker.ietf.org/doc/html/rfc1034#section-3.1
  12. https://www.iana.org/domains/root
  13. https://datatracker.ietf.org/doc/html/rfc1034#section-4.2
  14. https://datatracker.ietf.org/doc/html/rfc1034#section-4.1
  15. https://www.livescience.com/20727-internet-history.html
  16. https://historyofdomainnames.com/host-the-history-of-domain-names/
  17. https://www.livinginternet.com/i/iw_dns_history.htm
  18. https://datatracker.ietf.org/doc/html/rfc1034
  19. https://www.isi.edu/news/972810/and-the-dns-was-born/
  20. https://icannwiki.org/.edu
  21. https://www.inwx.de/blog/en/first-top-level-domains/
  22. https://www.onlydomains.com/blog/what-was-the-first-domain-name-ever-registered/
  23. https://tedium.co/2020/05/08/top-level-domain-history/
  24. https://www.internetsociety.org/ianatimeline/
  25. https://www.rfc-editor.org/rfc/rfc1591.html
  26. https://archive.icann.org/en/nsi/coopagmt-amend4-13sep95.htm
  27. https://www.icann.org/general/white-paper-05jun98.htm
  28. https://www.icann.org/en/announcements/details/icann-announces-selections-for-new-top-level-domains-16-11-2000-en
  29. https://www.icann.org/en/announcements/details/icann-issues-new-tld-application-process-overview-3-8-2000-en
  30. https://www.icann.org/tlds/application-process-03aug00.htm
  31. https://www.icann.org/en/announcements/details/icann-update---names-council-warns-pre-registration-of-speculative-new-domain-names-is-premature-29-9-2000-en
  32. https://archive.icann.org/en/tlds/new-gtld-eval-31aug04.pdf
  33. https://www.ntia.gov/speechtestimony/testimony-associate-administrator-alexander-icann-s-expansion-top-level-domains
  34. https://www.icann.org/en/history/icann-usg
  35. https://newgtlds.icann.org/en/program-status/statistics
  36. https://newgtldprogram.icann.org/en/application-rounds/round1
  37. https://gnso.icann.org/en/group-activities/active/new-gtld-subsequent-procedures
  38. https://newgtldprogram.icann.org/en/application-rounds/round2
  39. https://www.iana.org/help/gtld-delegation
  40. https://www.hoganlovells.com/en/publications/domain-name-news-march-2025
  41. https://www.dnib.com/articles/the-domain-name-industry-brief-q1-2025
  42. https://www.openprovider.com/blog/a-new-era-of-gtlds-is-coming
  43. https://www.icann.org/resources/pages/icann-iso-3166-2012-05-09-en
  44. https://www.iana.org/help/eligible-tlds
  45. https://www.iana.org/help/cctld-delegation
  46. https://www.icann.org/committees/gac/gac-cctldprinciples-23feb00.htm
  47. https://www.iana.org/help/cctld-delegation-answers
  48. https://www.afnic.fr/en/observatory-and-resources/expert-papers/ai-io-and-tv-and-their-surprising-stories/
  49. https://www.networksolutions.com/blog/what-is-cctld/
  50. https://www.dnib.com/articles/the-domain-name-industry-brief-q2-2025
  51. https://blog.1byte.com/how-many-domains-are-there/
  52. https://www.icann.org/resources/en/glossary.138
  53. https://www.icann.org/tlds/agreements/sponsored/sponsorship-agmt-29aug01.htm
  54. https://www.icann.org/tlds/
  55. https://www.icann.org/en/contracted-parties/consensus-policies/uniform-domain-name-dispute-resolution-policy/domain-name-dispute-resolution-policies-25-02-2012-en
  56. https://datatracker.ietf.org/doc/html/rfc5890
  57. https://datatracker.ietf.org/doc/html/rfc5891
  58. https://datatracker.ietf.org/doc/html/rfc3492
  59. https://www.icann.org/en/system/files/files/factsheet-idn-fast-track-oct09-en.pdf
  60. https://www.icann.org/resources/pages/faqs-5b-2012-02-25-en
  61. https://www.icann.org/en/system/files/files/idns-where-are-we-now-16jun21-en.pdf
  62. https://www.icann.org/en/resources/idn/fast-track/string-evaluation-completion/
  63. https://mpo.gov.cz/en/e-communications-and-postal-services/electronic-communications/digital-agenda/first-internationalized-country-code-top-level-domains--74754/
  64. https://www.icann.org/en/system/files/files/drd-ui-09sep13-en.pdf
  65. https://www.icann.org/en/system/files/files/idn-annual-report-2024-31jul24-en.pdf
  66. https://www.icann.org/resources/pages/synchronized-idn-cctlds-faqs-2012-02-25-en
  67. https://newgtlds.icann.org/en/about/idns
  68. https://www.icann.org/en/topics/new-gtlds/idn-variants-15feb10-en.pdf
  69. https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-07-26-en
  70. https://www.icann.org/en/topics/idn/idn-vip-integrated-issues-final-clean-20feb12-en.pdf
  71. https://www.icann.org/forms/idn_cctld
  72. https://www.openprovider.com/blog/all-you-need-to-know-about-idns
  73. https://www.dnib.com/articles/the-domain-name-industry-brief-q1-2024
  74. https://www.icann.org/eurid-unesco-deployment-08nov12-en.pdf
  75. https://www.diplomacy.edu/wp-content/uploads/2021/12/IGCBP2010_2011_Batayneh.pdf
  76. https://blog.netim.com/en/domain-names/idn-internationalized-domain-name-7870/
  77. https://dl.acm.org/doi/10.1109/TDSC.2024.3386905
  78. https://www.usenix.org/system/files/sec21-hu-hang.pdf
  79. https://gnso.icann.org/sites/default/files/policy/2024/draft/gnso-idn-epdp-phase2-final-report-07oct24-en.pdf
  80. https://www.iana.org/domains/arpa
  81. https://datatracker.ietf.org/doc/html/rfc3172
  82. https://namebeta.com/tlds/arpa
  83. https://www.iana.org/assignments/special-use-domain-names
  84. https://www.rfc-editor.org/rfc/rfc2606.html
  85. https://datatracker.ietf.org/doc/html/rfc2606
  86. https://www.rfc-editor.org/rfc/rfc6761.html
  87. https://datatracker.ietf.org/doc/html/rfc6761
  88. https://www.historyofdomains.com/
  89. https://snapshot.internetx.com/en/these-tlds-do-not-exist-anymore/
  90. https://www.iana.org/help/cctld-retirement
  91. https://www.iana.org/reports/2010/yu-report-01apr2010.html
  92. https://domainincite.com/30406-five-times-icann-deleted-a-cctld-and-what-it-means-for-io
  93. https://serverfault.com/questions/17255/top-level-domain-domain-suffix-for-private-network
  94. https://www.rfc-editor.org/rfc/rfc9476.html
  95. https://archive.icann.org/en/icp/tld-deleg-prac.html
  96. https://www.icann.org/resources/pages/what-2012-02-25-en
  97. https://www.icann.org/en/system/files/files/icann-role-dns-12mar08-en.pdf
  98. https://newgtlds.icann.org/en/applicants/global-support/faqs/faqs-en
  99. https://www.icann.org/en/about/agreements/iana/transition/iana-factsheet-24mar14-en.pdf
  100. https://www.iana.org/reports/2012/post-report-20120802.html
  101. https://blog.apnic.net/2025/03/18/the-root-of-the-dns-2/
  102. https://www.icann.org/en/system/files/files/gtld-drd-ui-10sep13-en.pdf
  103. https://www.verisign.com/what-we-do/root-zone-maintainer/
  104. https://blog.verisign.com/security/root-zone-maintainer-service-agreement-renewal/
  105. https://www.icann.org/en/announcements/details/stewardship-of-iana-functions-transitions-to-global-internet-community-as-contract-with-us-government-ends-1-10-2016-en
  106. https://www.icann.org/en/blogs/details/ushering-in-the-next-generation-of-root-zone-management-19-05-2022-en
  107. https://www.icann.org/policy
  108. https://gnso.icann.org/en/about/faqs
  109. https://www.icann.org/policy/implementation
  110. https://www.icann.org/resources/pages/policy-01-2012-02-25-en
  111. https://atlarge.icann.org/topics/policy-processes/background
  112. https://brill.com/view/journals/gg/27/2/article-p298_7.xml
  113. https://www.eff.org/deeplinks/2017/12/multi-stakeholder-internet-governance-dying
  114. https://www.icann.org/en/system/files/files/icann-multi-stakeholder-model-14apr08-en.pdf
  115. https://www.icann.org/en/about/annual-report/annual-report-2012-en.pdf
  116. https://newgtlds.icann.org/en/about/benefits-risks
  117. https://policyreview.info/pdf/policyreview-2013-2-134.pdf
  118. https://btlj.org/data/articles2015/vol29/29_AR/29-berkeley-tech-l-j-0865-0896.pdf
  119. https://www.ana.net/content/show/id/icann-topten
  120. https://domainincite.com/31117-us-government-opposes-most-new-gtlds
  121. https://digitalcommons.law.uga.edu/cgi/viewcontent.cgi?article=1041&context=jipl
  122. https://via.library.depaul.edu/cgi/viewcontent.cgi?article=1069&context=jatip
  123. https://www.icann.org/en/system/files/files/overview-cost-benefit-analyses-next-round-22jan24-en.pdf
  124. https://www.eff.org/deeplinks/2022/09/giving-big-corporations-closed-generic-top-level-domain-names-run-private-kingdoms
  125. https://www.bbc.com/news/business-47794353
  126. https://domainincite.com/20105-amazon-files-appeal-on-rejected-amazon-domain
  127. https://theconversation.com/amazon-wins-amazon-domain-name-aggravating-south-american-region-and-undermining-digital-commons-118186
  128. https://domainincite.com/13671-governments-kill-off-patagonias-dot-brand-bid
  129. https://gac.icann.org/work-products/public/patagonia-chile-78254-2012-11-20.pdf
  130. https://listverse.com/2018/06/10/top-10-top-level-domains-that-caused-controversies/
  131. https://cctld.ru/en/media/news/industry/38855/
  132. https://newgtlds.icann.org/en/program-status/odr/determination
  133. https://www.wipo.int/amc/en/domains/lro/
  134. https://www.jdsupra.com/legalnews/know-your-remedy-icanns-new-gtld-objec-99922/
  135. https://krebsonsecurity.com/2024/08/local-networks-go-global-when-domain-names-collide/
  136. https://www.corpad.org/?p=445
  137. https://efficientip.com/blog/a-year-in-review-google-zip-tld-dns-security-challenges/
  138. https://pulse.internetsociety.org/blog/where-did-dnssec-go-wrong
  139. https://www.cloudflare.com/learning/dns/dnssec/how-dnssec-works/
  140. https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/
  141. https://dnsrf.org/blog/new-gtld-abuse-analysis/index.html
  142. https://gac.icann.org/presentations/public/Interisle%2520GAC%2520Presentation%2520June%25202025.pdf
  143. https://www.brandsec.com.au/phishing-domains-and-new-gtlds-a-growing-security-concern/
  144. https://www.spamhaus.org/resource-hub/service-providers/abuse-takes-its-toll-on-top/
  145. https://www.icann.org/en/system/files/files/daar-monthly-report-31mar20-en.pdf
  146. https://www.centr.org/news/blog/icann77-dns-abuse.html
  147. https://newgtlds.icann.org/sites/default/files/statistical-analysis-dns-abuse-14sep17-en.pdf
  148. https://www.marketdataforecast.com/market-reports/domain-name-market
  149. https://netbeacon.org/how-have-the-gtld-contractual-amendments-impacted-dns-abuse/
  150. https://domainmoonshots.medium.com/the-economics-of-domain-names-supply-demand-and-pricing-45042657a1a3
  151. https://www.hostinger.com/blog/domain-name-market
  152. https://newgtldprogram.icann.org/en/node/57
  153. https://newgtldprogram.icann.org/en/application-rounds/round2/agb
  154. https://www.icann.org/en/blogs/details/update-on-new-gtld-program-next-round-27-05-2025-en
  155. https://newgtldprogram.icann.org/en/resources/faqs
  156. https://icannwiki.org/New_gTLD_Program:_Next_Round
  157. https://gac.icann.org/activity/new-gtld-program-next-round?language_id=9
  158. https://newgtldprogram.icann.org/en/news/2025
  159. https://www.facebook.com/icannorg/posts/-icann-continues-to-make-steady-progress-toward-launching-the-new-gtld-program-n/1259002592923804/
  160. https://www.icann.org/en/blogs/details/new-icann-publications-explain-blockchains-and-name-system-technologies-17-10-2024-en
  161. https://www.sidn.nl/en/news-and-blogs/domain-names-in-the-blockchain-hype-or-innovation
  162. https://ens.domains/
  163. https://unstoppabledomains.com/blog/categories/announcements/article/crypto-tld
  164. https://dl.acm.org/doi/10.1145/3589334.3645459
  165. https://domainincite.com/31251-blockchain-crisis-looming-for-new-gtld-next-round
  166. https://iptwins.com/2024/06/17/blockchain-a-dns-based-gtld-on-the-horizon/
  167. https://decentraweb.org/
  168. https://www.hostinger.com/tutorials/domain-name-statistics
Add your contribution
Related Hubs
User Avatar
No comments yet.