{"id":3770,"date":"2025-12-30T22:12:48","date_gmt":"2025-12-30T19:12:48","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/icann-launches-new-gtld-application-round-what-it-means-and-how-to-prepare\/"},"modified":"2025-12-30T22:12:48","modified_gmt":"2025-12-30T19:12:48","slug":"icann-launches-new-gtld-application-round-what-it-means-and-how-to-prepare","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/icann-launches-new-gtld-application-round-what-it-means-and-how-to-prepare\/","title":{"rendered":"ICANN Launches New gTLD Application Round: What It Means and How to Prepare"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>ICANN has confirmed that a new round for applying for custom generic top-level domains (gTLDs) is coming, and this time the process will be more structured, more policy-heavy, and more competitive than ever. If you have ever thought \u201cit would be powerful to own .brand, .city or .community for our ecosystem\u201d, this is the moment to start preparing. A new gTLD is not just a marketing asset; it is a piece of internet infrastructure that will sit alongside .com and .org and will require serious technical, financial, and governance planning. In this article, we walk through what the new ICANN gTLD application round actually is, who should realistically consider applying, how the policy and technical requirements have changed since the last round, and what kind of hosting, DNS, and server architecture you will need. As the dchost.com team, we will also share the kind of infrastructure patterns we use for high-availability DNS, registry-connected systems, and secure backend services so you can turn a big strategic idea into a stable, predictable TLD operation.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#What_the_New_ICANN_gTLD_Application_Round_Actually_Is\"><span class=\"toc_number toc_depth_1\">1<\/span> What the New ICANN gTLD Application Round Actually Is<\/a><\/li><li><a href=\"#Who_Should_Seriously_Consider_Applying_for_a_New_gTLD\"><span class=\"toc_number toc_depth_1\">2<\/span> Who Should Seriously Consider Applying for a New gTLD?<\/a><ul><li><a href=\"#1_Large_or_Ambitious_Brands_brand\"><span class=\"toc_number toc_depth_2\">2.1<\/span> 1. Large or Ambitious Brands (.brand)<\/a><\/li><li><a href=\"#2_Sector_or_Community_Registries\"><span class=\"toc_number toc_depth_2\">2.2<\/span> 2. Sector or Community Registries<\/a><\/li><li><a href=\"#3_Cities_and_Geographic_Regions\"><span class=\"toc_number toc_depth_2\">2.3<\/span> 3. Cities and Geographic Regions<\/a><\/li><li><a href=\"#4_Platforms_and_Ecosystems\"><span class=\"toc_number toc_depth_2\">2.4<\/span> 4. Platforms and Ecosystems<\/a><\/li><li><a href=\"#5_Who_Probably_Should_Not_Apply_Yet\"><span class=\"toc_number toc_depth_2\">2.5<\/span> 5. Who Probably Should Not Apply (Yet)<\/a><\/li><\/ul><\/li><li><a href=\"#Policy_and_Governance_Changes_You_Must_Understand\"><span class=\"toc_number toc_depth_1\">3<\/span> Policy and Governance Changes You Must Understand<\/a><ul><li><a href=\"#Refined_Registry_Obligations\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Refined Registry Obligations<\/a><\/li><li><a href=\"#Public_Interest_Safeguards_and_Closed_Generics\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Public Interest, Safeguards and Closed Generics<\/a><\/li><li><a href=\"#String_Contention_and_Objections\"><span class=\"toc_number toc_depth_2\">3.3<\/span> String Contention and Objections<\/a><\/li><\/ul><\/li><li><a href=\"#Architecture_Behind_a_gTLD_Registry_DNS_and_Hosting_Layers\"><span class=\"toc_number toc_depth_1\">4<\/span> Architecture Behind a gTLD: Registry, DNS and Hosting Layers<\/a><ul><li><a href=\"#1_The_Registry_Backend_SRS_EPP_and_Databases\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 1. The Registry Backend (SRS, EPP, and Databases)<\/a><\/li><li><a href=\"#2_Authoritative_DNS_Infrastructure\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 2. Authoritative DNS Infrastructure<\/a><\/li><li><a href=\"#3_WHOISRDAP_and_Public_Data_Services\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 3. WHOIS\/RDAP and Public Data Services<\/a><\/li><li><a href=\"#4_Security_Logging_and_Monitoring\"><span class=\"toc_number toc_depth_2\">4.4<\/span> 4. Security, Logging and Monitoring<\/a><\/li><li><a href=\"#5_Where_dchostcom_Fits_Into_This_Picture\"><span class=\"toc_number toc_depth_2\">4.5<\/span> 5. Where dchost.com Fits Into This Picture<\/a><\/li><\/ul><\/li><li><a href=\"#Application_Process_Costs_and_Timeline\"><span class=\"toc_number toc_depth_1\">5<\/span> Application Process, Costs and Timeline<\/a><ul><li><a href=\"#1_Pre-Application_Planning\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 1. Pre-Application Planning<\/a><\/li><li><a href=\"#2_Application_Submission\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 2. Application Submission<\/a><\/li><li><a href=\"#3_Evaluation_Objection_and_Contention_Phases\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 3. Evaluation, Objection, and Contention Phases<\/a><\/li><li><a href=\"#4_Contracting_Pre-Delegation_Testing_and_Delegation\"><span class=\"toc_number toc_depth_2\">5.4<\/span> 4. Contracting, Pre-Delegation Testing and Delegation<\/a><\/li><li><a href=\"#5_Cost_Considerations\"><span class=\"toc_number toc_depth_2\">5.5<\/span> 5. Cost Considerations<\/a><\/li><\/ul><\/li><li><a href=\"#Risk_Management_Security_Abuse_and_Brand_Protection\"><span class=\"toc_number toc_depth_1\">6<\/span> Risk Management: Security, Abuse and Brand Protection<\/a><ul><li><a href=\"#1_Abuse_Mitigation_and_Reputation\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 1. Abuse Mitigation and Reputation<\/a><\/li><li><a href=\"#2_Domain_Security_and_Locking\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 2. Domain Security and Locking<\/a><\/li><li><a href=\"#3_Brand_Protection_and_Conflicts\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 3. Brand Protection and Conflicts<\/a><\/li><\/ul><\/li><li><a href=\"#How_We_Suggest_Planning_Your_Next_Steps\"><span class=\"toc_number toc_depth_1\">7<\/span> How We Suggest Planning Your Next Steps<\/a><ul><li><a href=\"#1_Clarify_the_Strategic_Why\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 1. Clarify the Strategic Why<\/a><\/li><li><a href=\"#2_Map_Requirements_to_Infrastructure\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 2. Map Requirements to Infrastructure<\/a><\/li><li><a href=\"#3_Prototype_Early_Even_Before_Applying\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 3. Prototype Early, Even Before Applying<\/a><\/li><li><a href=\"#4_Align_with_Your_Existing_Domain_Portfolio\"><span class=\"toc_number toc_depth_2\">7.4<\/span> 4. Align with Your Existing Domain Portfolio<\/a><\/li><li><a href=\"#5_Build_a_Cross-Functional_Team\"><span class=\"toc_number toc_depth_2\">7.5<\/span> 5. Build a Cross-Functional Team<\/a><\/li><\/ul><\/li><li><a href=\"#Closing_Thoughts_Turning_a_Big_Idea_into_a_Stable_TLD\"><span class=\"toc_number toc_depth_1\">8<\/span> Closing Thoughts: Turning a Big Idea into a Stable TLD<\/a><\/li><\/ul><\/div>\n<h2><span id=\"What_the_New_ICANN_gTLD_Application_Round_Actually_Is\">What the New ICANN gTLD Application Round Actually Is<\/span><\/h2>\n<p>ICANN (the Internet Corporation for Assigned Names and Numbers) coordinates the global Domain Name System. Every few years, it opens an application window where organizations can apply to run their own gTLDs \u2013 new extensions like .brand, .city, .shop, or specialized community strings.<\/p>\n<p>The last major new gTLD round was launched in 2012 and resulted in more than a thousand new extensions entering the root zone. Since then, ICANN has spent years refining policies, evaluating what worked and what did not, and negotiating the balance between innovation, security, competition, and end-user protection. The newly announced round is the first large-scale opportunity since that era to apply for your own extension.<\/p>\n<p>When ICANN says \u201cnew gTLD application round\u201d, it does <strong>not<\/strong> mean simply registering a new domain name. You are applying to become a <strong>registry operator<\/strong> \u2013 the entity responsible for running an entire namespace, setting policy for who can register names under it, and maintaining the technical services (DNS, registry database, WHOIS\/RDAP, and more) that keep it functioning 24\/7.<\/p>\n<p>If this sounds like running a small slice of the internet, that is exactly what it is. The reward can be strategic control over your brand or community identity at the DNS root level \u2013 but it also comes with obligations and operational complexity that you must be ready for.<\/p>\n<h2><span id=\"Who_Should_Seriously_Consider_Applying_for_a_New_gTLD\">Who Should Seriously Consider Applying for a New gTLD?<\/span><\/h2>\n<p>A new gTLD is not a fit for everyone. In our work with customers on domains, hosting, and infrastructure planning, we usually see a realistic case for a new gTLD in a few specific scenarios:<\/p>\n<h3><span id=\"1_Large_or_Ambitious_Brands_brand\">1. Large or Ambitious Brands (.brand)<\/span><\/h3>\n<p>Global or fast-scaling brands may want a closed or restricted .brand namespace such as .yourbrand. This can be used to:<\/p>\n<ul>\n<li>Unify all digital properties under a controlled, trusted extension<\/li>\n<li>Run short, clean URLs for campaigns (promo.yourbrand, pay.yourbrand)<\/li>\n<li>Strengthen anti-phishing efforts by clearly separating official domains from lookalikes<\/li>\n<\/ul>\n<p>Brand TLDs tie directly into long-term domain strategy and defensive registrations. If you are not yet confident in your brand\u2019s domain posture, it is worth reviewing a defensive registration approach first. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/marka-korumasi-icin-defansif-domain-satin-alma-stratejileri-typosquat-idn-ve-marka-uzantilari\/\">defensive domain registration strategy for typosquats, IDNs, and brand TLDs<\/a> is a good baseline before you start dreaming about your own dot.<\/p>\n<h3><span id=\"2_Sector_or_Community_Registries\">2. Sector or Community Registries<\/span><\/h3>\n<p>Some organizations want to operate a TLD for an entire vertical or community, such as a professional association, an open-source ecosystem, or an industry initiative. These often run under a shared set of rules and eligibility criteria (for example, only members or certified professionals can register).<\/p>\n<p>Here, the registry is a neutral infrastructure provider for many independent registrants. This requires:<\/p>\n<ul>\n<li>Clear, enforceable registration policies<\/li>\n<li>An abuse management framework (phishing, malware, spam)<\/li>\n<li>Technical capacity to run reliable DNS and registry systems for many tenants<\/li>\n<\/ul>\n<h3><span id=\"3_Cities_and_Geographic_Regions\">3. Cities and Geographic Regions<\/span><\/h3>\n<p>City and regional TLDs (.city, .region) can concentrate tourism, local businesses, cultural institutions, and citizens into a unified namespace. Municipalities or regional authorities can use them to:<\/p>\n<ul>\n<li>Standardize official digital addresses for public services and agencies<\/li>\n<li>Create a recognizable badge of local trust for businesses<\/li>\n<li>Offer local-language or local-script domains for inclusivity<\/li>\n<\/ul>\n<p>Geo-TLDs add another layer: cooperation with local stakeholders and sometimes legal requirements around who can apply and how data is processed.<\/p>\n<h3><span id=\"4_Platforms_and_Ecosystems\">4. Platforms and Ecosystems<\/span><\/h3>\n<p>Large platforms \u2013 think marketplaces, SaaS ecosystems, or app platforms \u2013 sometimes want their own TLD to structure third-party participants. Sub-brands, merchants or partners get names under the platform\u2019s TLD and must follow predefined policies.<\/p>\n<p>We often see this idea emerge during architecture or capacity planning sessions for multi-tenant SaaS. If you are already thinking about <a href=\"https:\/\/www.dchost.com\/blog\/en\/saas-uygulamalari-icin-cok-kiracili-mimari-turleri-ve-dogru-hosting-altyapisi-secimi\/\">multi-tenant architectures for SaaS apps and the hosting infrastructure behind them<\/a>, a dedicated TLD becomes an interesting long-term control point.<\/p>\n<h3><span id=\"5_Who_Probably_Should_Not_Apply_Yet\">5. Who Probably Should Not Apply (Yet)<\/span><\/h3>\n<p>If you are an individual site owner, a small business with limited IT capacity, or a brand that is still stabilizing its marketing and naming strategy, a gTLD is usually overkill. The costs (both application and ongoing operations) are substantial, and you will need to maintain compliance and technical resilience for years.<\/p>\n<p>In those cases, choosing the right combination of classic domains (.com, ccTLDs, relevant existing new gTLDs) is usually a better fit. Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/alan-adi-stratejisi-nasil-kurulur-cctld-mi-gtld-mi-uluslararasi-seoda-hangi-yol-ne-zaman-dogru\/\">building a calm domain strategy with ccTLD vs gTLD and international SEO<\/a> is a solid place to start.<\/p>\n<h2><span id=\"Policy_and_Governance_Changes_You_Must_Understand\">Policy and Governance Changes You Must Understand<\/span><\/h2>\n<p>The upcoming ICANN round is not a copy\u2013paste of 2012. Policy work over the past decade has led to new obligations, clearer guardrails, and some new opportunities.<\/p>\n<h3><span id=\"Refined_Registry_Obligations\">Refined Registry Obligations<\/span><\/h3>\n<p>Registry operators sign a detailed Registry Agreement with ICANN. Compared with the previous round, you should expect:<\/p>\n<ul>\n<li><strong>Clearer abuse mitigation duties<\/strong> \u2014 expectations for handling phishing, malware, and DNS abuse have tightened.<\/li>\n<li><strong>Stronger data protection expectations<\/strong> \u2014 especially where <a href=\"https:\/\/www.dchost.com\/domain\/register\">domain registration<\/a> data intersects with privacy regulations.<\/li>\n<li><strong>Formal service-level commitments<\/strong> \u2014 uptime and performance targets for DNS and registry services.<\/li>\n<\/ul>\n<p>We have already covered many of these policy themes in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/icann-yeni-gtld-politikalari-kapsamli-teknik-ve-stratejik-rehber\/\">ICANN New gTLD Policies and what they mean for your domains<\/a>. If you are starting a gTLD project, that deeper policy dive is worth reading alongside this more infrastructure-focused overview.<\/p>\n<h3><span id=\"Public_Interest_Safeguards_and_Closed_Generics\">Public Interest, Safeguards and Closed Generics<\/span><\/h3>\n<p>ICANN has spent years discussing \u201cpublic interest\u201d safeguards \u2013 especially for domain spaces related to regulated sectors (health, finance, law, etc.) and for so-called \u201cclosed generic\u201d TLDs where a single entity wants exclusive control over a generic term.<\/p>\n<p>You should expect more scrutiny on:<\/p>\n<ul>\n<li>How you prevent consumer confusion and harmful uses<\/li>\n<li>Whether a closed or restricted namespace makes sense for the broader internet community<\/li>\n<li>How you will resolve conflicts and complaints over eligibility<\/li>\n<\/ul>\n<h3><span id=\"String_Contention_and_Objections\">String Contention and Objections<\/span><\/h3>\n<p>Two or more applicants may apply for the same or confusingly similar string. ICANN has well-defined processes for:<\/p>\n<ul>\n<li><strong>String similarity evaluations<\/strong><\/li>\n<li><strong>Objection procedures<\/strong> (e.g. from rights holders, communities, or existing operators)<\/li>\n<li><strong>Contention resolution<\/strong> \u2014 in some cases, auctions<\/li>\n<\/ul>\n<p>Monitoring these policies early helps you choose a string that is realistic, defendable, and strategically aligned with your brand and legal position.<\/p>\n<p>To keep up with the broader domain policy trends beyond gTLDs, our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/icann-alan-adi-politikalarindaki-degisiklikler-domain-sahipleri-icin-yol-haritasi\/\">ICANN domain policy changes and what they mean for your domains in 2025<\/a> gives a wider context of how the domain space is tightening overall.<\/p>\n<h2><span id=\"Architecture_Behind_a_gTLD_Registry_DNS_and_Hosting_Layers\">Architecture Behind a gTLD: Registry, DNS and Hosting Layers<\/span><\/h2>\n<p>Running a gTLD is not just a legal and branding project; it is fundamentally a <strong>hosting and infrastructure<\/strong> project. At dchost.com we live in this layer every day, so let\u2019s break down what actually runs under a TLD.<\/p>\n<h3><span id=\"1_The_Registry_Backend_SRS_EPP_and_Databases\">1. The Registry Backend (SRS, EPP, and Databases)<\/span><\/h3>\n<p>The registry backend is your \u201csource of truth\u201d for all domain records in your TLD. Key components include:<\/p>\n<ul>\n<li><strong>Shared Registration System (SRS)<\/strong> \u2014 the core application that manages domain objects, contacts, and name servers.<\/li>\n<li><strong>EPP (Extensible Provisioning Protocol) servers<\/strong> \u2014 the interface that ICANN-accredited registrars use to create, renew, transfer, and delete domains.<\/li>\n<li><strong>Relational databases<\/strong> \u2014 typically highly-available MySQL\/MariaDB or PostgreSQL clusters with replication, point-in-time recovery, and strict backup procedures.<\/li>\n<\/ul>\n<p>You will need to design the registry backend like a mission-critical SaaS: redundant <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s, separate database nodes, and clearly documented <strong>disaster recovery<\/strong>. Our general guidance on <a href=\"https:\/\/www.dchost.com\/blog\/en\/yedekleme-stratejisi-nasil-planlanir-blog-e-ticaret-ve-saas-siteleri-icin-rpo-rto-rehberi\/\">designing backup strategies with proper RPO\/RTO<\/a> applies directly here \u2014 except the stakes are higher because it is not just one site, but an entire TLD.<\/p>\n<h3><span id=\"2_Authoritative_DNS_Infrastructure\">2. Authoritative DNS Infrastructure<\/span><\/h3>\n<p>Every domain under your TLD ultimately resolves through the authoritative DNS servers you operate or contract. ICANN expects redundancy and robustness. In practice this means:<\/p>\n<ul>\n<li><strong>Multiple geographically distributed DNS nodes<\/strong> \u2014 often with anycast routing for low latency and resilience.<\/li>\n<li><strong>DNSSEC support<\/strong> \u2014 your TLD must be signed, and you must handle key rollovers safely.<\/li>\n<li><strong>Strict uptime<\/strong> \u2014 downtime at the TLD DNS layer impacts every domain below it.<\/li>\n<\/ul>\n<p>We have an in-depth guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dnssec-nedir-ne-ise-yarar-alan-adiniz-ve-hostinginiz-icin-adim-adim-dnssec-kurulum-rehberi\/\">what DNSSEC is and how to set it up safely<\/a>, including key rollover without breaking resolution. If you are planning to be a TLD operator, DNSSEC goes from \u201cnice-to-have\u201d to \u201cnon-negotiable core duty\u201d.<\/p>\n<h3><span id=\"3_WHOISRDAP_and_Public_Data_Services\">3. WHOIS\/RDAP and Public Data Services<\/span><\/h3>\n<p>Registry operators must publish domain registration data through WHOIS and\/or RDAP services. Technically, this involves:<\/p>\n<ul>\n<li>One or more API\/web services backed by your registry database<\/li>\n<li>Rate limiting and abuse control to avoid scraping and DDoS<\/li>\n<li>Careful handling of personal data to stay compatible with privacy regulations<\/li>\n<\/ul>\n<p>From a hosting perspective, these are HTTP services behind load balancers, with WAF rules, rate limiting, and log retention policies similar to any high-traffic API you might run.<\/p>\n<h3><span id=\"4_Security_Logging_and_Monitoring\">4. Security, Logging and Monitoring<\/span><\/h3>\n<p>A TLD is a high-value target. As a registry, you must assume you will face:<\/p>\n<ul>\n<li>DDoS attacks against DNS servers or public APIs<\/li>\n<li>Credential stuffing and phishing attempts targeting your control panels<\/li>\n<li>Attempts to abuse your TLD for spam, malware, or brand impersonation<\/li>\n<\/ul>\n<p>This is where classic hosting practices meet registry-specific concerns. You will need:<\/p>\n<ul>\n<li><strong>Hardened VPS or dedicated servers<\/strong> with properly configured firewalls and access controls<\/li>\n<li><strong>Centralized logging<\/strong> across DNS, application servers, and databases<\/li>\n<li><strong>Metrics and alerts<\/strong> to detect anomalies quickly<\/li>\n<\/ul>\n<p>Our articles on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucu-guvenligi-pratik-olceklenebilir-ve-dogrulanabilir-yaklasimlar\/\">securing a VPS for real-world threats<\/a> and <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-izleme-ve-uyari-nasil-kurulur-prometheus-grafana-ve-node-exporter-ile-sessiz-alarmlari-konusturmak\/\">setting up monitoring and alerts with Prometheus and Grafana<\/a> illustrate the same patterns you will apply at TLD scale \u2013 just with more redundancy and stronger SLAs.<\/p>\n<h3><span id=\"5_Where_dchostcom_Fits_Into_This_Picture\">5. Where dchost.com Fits Into This Picture<\/span><\/h3>\n<p>At dchost.com we operate the layers you need to build a registry stack: reliable <strong>VPS<\/strong> for application tiers, <strong>dedicated servers<\/strong> and <strong>colocation<\/strong> options for high-availability database clusters, and resilient <strong>domain and DNS<\/strong> services for your broader portfolio. Whether you choose to work with a specialized registry software provider or build more in-house, you still need solid, well-monitored infrastructure to host it on \u2014 that is exactly the kind of environment we design and maintain daily.<\/p>\n<h2><span id=\"Application_Process_Costs_and_Timeline\">Application Process, Costs and Timeline<\/span><\/h2>\n<p>ICANN\u2019s formal Applicant Guidebook for this round will define precise dates and procedures, but the high-level lifecycle will likely resemble the previous round, with more clarity and automation.<\/p>\n<h3><span id=\"1_Pre-Application_Planning\">1. Pre-Application Planning<\/span><\/h3>\n<p>Before the window even opens, successful applicants usually spend months on:<\/p>\n<ul>\n<li><strong>String selection<\/strong> \u2014 choosing the TLD string itself, including variants in non-Latin scripts if relevant.<\/li>\n<li><strong>Policy design<\/strong> \u2014 deciding who can register, under what conditions, and with what verification (if any).<\/li>\n<li><strong>Business modeling<\/strong> \u2014 projecting demand, pricing (if open), and long-term sustainability.<\/li>\n<li><strong>Technical architecture<\/strong> \u2014 whether you will use an outsourced registry backend provider or build your own stack on top of robust hosting, VPS, and dedicated server infrastructure.<\/li>\n<\/ul>\n<h3><span id=\"2_Application_Submission\">2. Application Submission<\/span><\/h3>\n<p>During the official application window, you will submit a detailed application covering:<\/p>\n<ul>\n<li>Applicant identity and financial stability<\/li>\n<li>Technical capability and infrastructure plans<\/li>\n<li>Operational and abuse mitigation policies<\/li>\n<li>Rights protection mechanisms (for trademarks and brand owners)<\/li>\n<\/ul>\n<p>Expect significant documentation, supporting evidence, and clear written descriptions of your technical design, including DNSSEC deployment, uptime targets, and backup\/restore procedures for registry data.<\/p>\n<h3><span id=\"3_Evaluation_Objection_and_Contention_Phases\">3. Evaluation, Objection, and Contention Phases<\/span><\/h3>\n<p>After submission, your application will go through:<\/p>\n<ul>\n<li><strong>Initial evaluation<\/strong> \u2014 ICANN reviews your technical, financial, and operational plans.<\/li>\n<li><strong>Public comment and objection periods<\/strong> \u2014 others can raise concerns (e.g., trademark holders, communities).<\/li>\n<li><strong>String contention resolution<\/strong> \u2014 if multiple parties apply for the same or confusingly similar string.<\/li>\n<\/ul>\n<p>During these phases you may need to clarify or adjust aspects of your plan. This is where having a concrete, already-tested infrastructure design (not just theory) helps convince evaluators you can run the TLD reliably.<\/p>\n<h3><span id=\"4_Contracting_Pre-Delegation_Testing_and_Delegation\">4. Contracting, Pre-Delegation Testing and Delegation<\/span><\/h3>\n<p>If your application is approved, you will sign a Registry Agreement with ICANN, then complete pre-delegation testing. This is where you must demonstrate that your DNS, registry backend, and related services work according to ICANN\u2019s requirements.<\/p>\n<p>From an infrastructure perspective, you need your production environment ready \u2014 not just diagrams. This often involves:<\/p>\n<ul>\n<li>Production-ready VPS and dedicated servers in multiple data centers<\/li>\n<li>Live DNS clusters with DNSSEC enabled<\/li>\n<li>Monitoring, logging, and backup routines running and documented<\/li>\n<\/ul>\n<p>Once you pass pre-delegation tests, your TLD is added to the root zone, and you can start operating it under your agreed policy.<\/p>\n<h3><span id=\"5_Cost_Considerations\">5. Cost Considerations<\/span><\/h3>\n<p>A gTLD application is not cheap. While exact fees for this round will be finalized by ICANN, you should anticipate:<\/p>\n<ul>\n<li>An application fee in the tens of thousands of USD<\/li>\n<li>Ongoing ICANN fees per year and per-domain (if open)<\/li>\n<li>Legal and consulting costs for policy and contract work<\/li>\n<li>Infrastructure and operations costs (servers, DNS, support, monitoring)<\/li>\n<\/ul>\n<p>The infrastructure part is one area where careful design can make a big difference. For example, using well-sized VPS clusters for stateless services, reserving dedicated servers for databases and storage-heavy functions, and leveraging colocation for specialized hardware can keep recurring costs predictable without sacrificing reliability.<\/p>\n<h2><span id=\"Risk_Management_Security_Abuse_and_Brand_Protection\">Risk Management: Security, Abuse and Brand Protection<\/span><\/h2>\n<p>Owning a TLD does not automatically make your namespace safe. You must actively manage risk on several fronts.<\/p>\n<h3><span id=\"1_Abuse_Mitigation_and_Reputation\">1. Abuse Mitigation and Reputation<\/span><\/h3>\n<p>ICANN and the broader internet community expect registries to react quickly to abuse: phishing, malware hosting, botnet control domains, and large-scale spam. If your TLD becomes associated with abuse, browsers, email providers, and security vendors may treat it with distrust.<\/p>\n<p>Practical steps include:<\/p>\n<ul>\n<li><strong>Clear AUP and enforcement mechanisms<\/strong> in your registration policy<\/li>\n<li><strong>Abuse reporting channels<\/strong> and SLAs for investigation<\/li>\n<li><strong>Automation<\/strong> to detect patterns in DNS and registration data<\/li>\n<\/ul>\n<p>Many of the techniques we use to protect hosting environments from abuse and compromise (centralized logging, anomaly detection, WAF rules, and rate limiting) apply equally well here.<\/p>\n<h3><span id=\"2_Domain_Security_and_Locking\">2. Domain Security and Locking<\/span><\/h3>\n<p>Your own core domains under the new TLD \u2013 registry portals, support sites, APIs \u2013 must be especially well-protected. Techniques like registry lock, transfer lock, strong authentication and DNSSEC all matter.<\/p>\n<p>We have a dedicated domain security guide, <a href=\"https:\/\/www.dchost.com\/blog\/en\/alan-adi-guvenligi-rehberi-registrar-lock-dnssec-whois-gizliligi-ve-2fa\/\">Domain security best practices: registrar lock, DNSSEC, WHOIS privacy and 2FA<\/a>, which outlines the same practices you will want to enforce for your own high-value domains and encourage (or require) for critical registrants.<\/p>\n<h3><span id=\"3_Brand_Protection_and_Conflicts\">3. Brand Protection and Conflicts<\/span><\/h3>\n<p>Even as a registry, you remain a brand owner operating in a global domain marketplace. You may still need:<\/p>\n<ul>\n<li>Defensive registrations in other TLDs to avoid confusion<\/li>\n<li>Monitoring for typosquats and lookalikes<\/li>\n<li>UDRP\/URS strategies for disputes that spill beyond your own TLD<\/li>\n<\/ul>\n<p>If your TLD is part of a broader migration or rebrand, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/alan-adi-degistirirken-seo-kaybetmemek\/\">changing your domain without losing SEO<\/a> can help you plan redirects, SSL, and DNS changes so that moving key web properties under your new TLD does not damage search visibility.<\/p>\n<h2><span id=\"How_We_Suggest_Planning_Your_Next_Steps\">How We Suggest Planning Your Next Steps<\/span><\/h2>\n<p>For organizations eyeing the new ICANN gTLD round, we usually recommend a staged approach that combines policy, technical, and business work rather than treating them as separate tracks.<\/p>\n<h3><span id=\"1_Clarify_the_Strategic_Why\">1. Clarify the Strategic Why<\/span><\/h3>\n<p>Start with a short but honest internal document answering:<\/p>\n<ul>\n<li>What problem does this TLD solve for us or our community?<\/li>\n<li>How will success be measured in 5\u201310 years?<\/li>\n<li>Is this primarily about brand control, security, community building, or revenue?<\/li>\n<\/ul>\n<p>This helps cut through \u201cit would be cool\u201d thinking and forces a realistic conversation about resourcing and long-term commitment.<\/p>\n<h3><span id=\"2_Map_Requirements_to_Infrastructure\">2. Map Requirements to Infrastructure<\/span><\/h3>\n<p>Translate your policy and business goals into concrete infrastructure requirements. For example:<\/p>\n<ul>\n<li>If you want a closed .brand with a few thousand internal domains, you might favor a compact registry backend, a small but very robust DNS footprint, and strong integration with your internal identity systems.<\/li>\n<li>If you aim for an open, high-volume TLD, you will need horizontally scalable application servers, database replicas, and careful capacity planning for DNS and WHOIS\/RDAP traffic.<\/li>\n<\/ul>\n<p>This is where your choice between VPS clusters, dedicated servers, and colocation becomes real: each layer should be sized to your realistic year\u20111, year\u20113, and year\u20115 traffic and growth expectations.<\/p>\n<h3><span id=\"3_Prototype_Early_Even_Before_Applying\">3. Prototype Early, Even Before Applying<\/span><\/h3>\n<p>We strongly recommend building a working prototype of your registry backend and DNS layout on a test subdomain or private namespace long before pre-delegation testing. On our side, we typically help customers spin up:<\/p>\n<ul>\n<li>A small registry-like application stack on VPS instances<\/li>\n<li>A replicated database cluster on dedicated servers<\/li>\n<li>Authoritative DNS nodes, signed with DNSSEC, in multiple locations<\/li>\n<\/ul>\n<p>Even if you change vendors or software later, the experience of operating a small, always-on, DNS-and-database-heavy service prepares your team for the reality of a TLD.<\/p>\n<h3><span id=\"4_Align_with_Your_Existing_Domain_Portfolio\">4. Align with Your Existing Domain Portfolio<\/span><\/h3>\n<p>A new gTLD does not replace your existing domains overnight. You will still manage .com, ccTLDs, and other gTLDs for years. Think through:<\/p>\n<ul>\n<li>Which properties migrate to the new TLD and on what timeline<\/li>\n<li>What will remain on legacy domains for SEO, email stability, or regional reasons<\/li>\n<li>How redirects, certificates, and DNS records will be managed across all of them<\/li>\n<\/ul>\n<p>Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/alan-adi-portfoy-yonetimi-onlarca-domaini-kontrol-altina-alma-rehberi\/\">domain portfolio management for renewals, billing and brand protection<\/a> is a useful counterpart here; a TLD just adds one more (very special) asset into that portfolio.<\/p>\n<h3><span id=\"5_Build_a_Cross-Functional_Team\">5. Build a Cross-Functional Team<\/span><\/h3>\n<p>Successful TLD projects are not purely IT or purely marketing. You will need at least:<\/p>\n<ul>\n<li>Technical leads for DNS, servers, security and monitoring<\/li>\n<li>Legal and policy expertise for ICANN processes, contracts and rights protection<\/li>\n<li>Operational staff for customer support and abuse handling (if open)<\/li>\n<li>Brand\/communications roles to explain the TLD to users and partners<\/li>\n<\/ul>\n<p>From our side at dchost.com, we typically collaborate with your technical and operations teams on the hosting, DNS, and security design, while your legal and marketing teams focus on policies, brand positioning and user communication.<\/p>\n<h2><span id=\"Closing_Thoughts_Turning_a_Big_Idea_into_a_Stable_TLD\">Closing Thoughts: Turning a Big Idea into a Stable TLD<\/span><\/h2>\n<p>The newly launched ICANN gTLD application round is a rare chance to move from being a domain customer to being an internet infrastructure operator. It is easy to get excited about owning .yourbrand or .yourcity; the real work lies in designing and running the registry, DNS, and security layers so that every domain under your TLD feels as boringly reliable as .com.<\/p>\n<p>If you are seriously considering an application, the best time to start is before the formal window opens: clarify your strategy, sketch policies, and begin prototyping the hosting and DNS architecture you will rely on later. Treat it like any other critical production system: capacity planning, redundancy, backups, monitoring, and clear runbooks for incidents and changes.<\/p>\n<p>As the dchost.com team, we spend our days building and maintaining exactly these types of architectures for domains, hosting, VPS, dedicated servers and colocation setups. If you want to explore what your future registry stack could look like \u2014 from DNSSEC-signed authoritative servers to resilient registry databases and secure management access \u2014 we are ready to help you turn a big idea into a concrete, testable infrastructure plan. The next gTLD round will reward those who combine vision with solid engineering; now is the time to align both.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>ICANN has confirmed that a new round for applying for custom generic top-level domains (gTLDs) is coming, and this time the process will be more structured, more policy-heavy, and more competitive than ever. If you have ever thought \u201cit would be powerful to own .brand, .city or .community for our ecosystem\u201d, this is the moment [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3771,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[32,24,33,30],"tags":[],"class_list":["post-3770","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-alan-adi","category-hosting","category-nasil-yapilir","category-nedir"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3770","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3770"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3770\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3771"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3770"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3770"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3770"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}