.cl domain requirements every reseller should know

How to sell .link premium domains to your customers

When a DNS provider loses its own nameservers and gets back a SERVFAIL

Subdirectory, subdomain, or .blog? How to advise clients on a content hub

Namecheap vs Openprovider: which is the best domain reseller platform?

Best wholesale domain registration (cost-price, not just discounted)

5 Best domain reseller APIs (REST, tld coverage, and pricing compared)

7 Best Namecheap alternatives (cheaper renewals, reseller-ready, no upsells)

7 Best domain reseller programs for higher margins

Is a .design domain good for design agencies? The truth about pricing and trust in 2026

Is a .design domain good for design agencies?

How the right domain API platform turns a complex ccTLD portfolio into a growth engine

7 things to know before registering a .CA domain name

What the .com price increase in 2026 means for your domain portfolio

What is a .tech domain and why are tech startups choosing it?

Why .link premium domains are worth the investment

Why LATAM resellers should add .mx domains to their portfolio

The .co TLD turns 16 years old in 2026

25 years of .nl: what every Dutch domain reseller needs to know to grow a profitable portfolio

How the Openprovider hackathon brought every customer into one view

The 7 best domain registrars of 2026

What is a .io domain extension and what does it stand for?

Why add .org to your domain reseller portfolio

Why subscription-based domain pricing outperforms markup models at scale

infrastructure platforms in domain reselling

The rise of infrastructure platforms in domain reselling

How infrastructure teams reduce support load with domain automation workflows through APIs

Why your clients need a .CL domain when expanding into Chile

consolidate Canadian client domains one platform

How to consolidate Canadian client domains into one platform

Why DNS failures increase when infrastructure is not centrally controlled

Why domain resellers should revisit .blog in 2026

DevNomads: API-first infrastructure and total margin control

Why a .cat domain strengthens your local online identity

Is your domain strategy ready for the World Cup?

Why domain resellers hit a structural growth ceiling in fragmented setups

What resellers with fragmented infrastructure are missing from a consolidated Reseller Control Panel

What domain infrastructure failures look like in real production environments

.dk registry is changing its administration model: what it means for your portfolio

How recurring revenue accelerates when infrastructure services like email, SSL, and DNS are centralized

.com vs. .CA which is best for Canadian businesses?

Why traditional domain pricing models become unstable under portfolio growth

ccTLD restrictions in 2026: which country domains you can actually sell as a reseller

Why API-first infrastructure is replacing registrar portals in reseller operations

Why manual domain renewal processes fail as portfolios scale

How fragmented domain infrastructure steadily erodes margin at scale

Your essential domain health check guide

Why domain operations break after 1,000 domains

The hidden domain renewal risk most resellers find too late

Personal brands, creators, and artists: the growing importance of identity-driven domains

How to fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chrome

ERR_SSL_PROTOCOL_ERROR: what it means and how to fix it

.AI and .TECH domains are a smart investment cover image

The complete guide on .ai and .tech domains: sales, volumes, and value

.ai vs .com choosing the right domain for your startup

.ai vs. .com: choosing the right domain for AI startups

Nominate your .org domain and win up to $50,000!

Domain Pricing Registration vs Renewal Costs

Busting the biggest myths about Web3 for domain resellers

7 cheap email hosting providers of 2026

TLD and .com domain price increase in 2026: what Verisign, SIDN, and domain owners say

Who really controls your clients' domains, and why it matters

Who really controls your clients’ domains, and why it matters

Unstoppable domains alternative: why consider Openprovider for domain resellers in 2026?

Premium domain risks explained: trademark, security, and valuation

Why so many domain resellers choose Openprovider as their domain registrar

The .asia upsell opportunity: how resellers can serve Asian-focused businesses in Europe

How to use AI for domain sales: a step-by-step guide

The hidden operational costs of managing domains, SSL, and email across multiple providers

How to negotiate a domain name: expert tips and strategy guide

How to choose a domain infrastructure partner you can trust

How AI-powered domain name search transformed domain name discovery: the .me registry’s journey

Openprovider vs Netim: what do smart domain resellers look for

Atak domains alternative: why consider Openprovider as a domain reseller in 2026?

ConnectReseller alternative: why switch to Openprovider in 2026

Preparing your domain and hosting infrastructure for the vibe coding era

How digital agencies can turn domain infrastructure into a competitive advantage

Exploring reseller alternatives to Gandi: Openprovider as a reseller-first choice

Domain portfolio management: 6 strategies for success

The business case for multi-year domain registrations

Enhancing client relationships: a guide for hosting resellers

6 domain trends resellers should watch in 2026 and beyond

Domain Name API alternative: Why resellers are choosing Openprovider instead

How predictable pricing models help domain resellers protect their margins

How to reduce churn in hosting and domain businesses

How MSPs can centralize domain, SSL, and DNS management

Is your business email at risk? Why DMARC matters in 2026

AI.com sold for $70M: what the record domain deal means for premium domains and resellers

How to upsell security services your customers actually want 

How to set up white-label domain services for your hosting business

What is EasyDMARC? How to protect your email infrastructure

EasyDMARC: Protecting your email infrastructure in the AI age

How a .blog domain helps creators stand out

The affordable way to centralize your digital infrastructure without compromising quality

How to automate domain management using APIs

Choosing the right ResellerClub alternative in 2026

.blog: one simple domain, five real-world ways to use it

New gTLDs vs ccTLDs: which should you sell to clients?

What is RDAP? The new WHOIS protocol explained

DNS explained for non-technical business owners

Vibe coding cybersecurity Openprovider Netcraft

The rise of vibe coding as a cybersecurity weapon

DNSSEC: what it is, why it matters, and how to enable it

Choosing the right domain name for affiliate marketing

What is a domain registry vs registrar vs reseller?

The most profitable domain platforms for hosting companies and marketing agencies

Openprovider Podcast: Inside the frontlines of cybersecurity in the AI age

.com .net vs .biz: which is the better domain extension for your domain portfolio?

Inside domain pricing with Arno Vis, Openprovider CEO

Inside domain pricing with Arno Vis

For resellers selling into Chile, or building out a broader Latin America TLD offering, <a href="https://www.openprovider.com/domains/tlds/cl">.cl</a> is the local domain extension clients will ask for. You should therefore know the rules before you give your client a price.



Eligibility for .cl is straightforward. What catches resellers out is everything that happens after registration: what <a href="https://nic.cl/">NIC Chile</a> expects from the domain holder, what happens if a client&#8217;s data goes stale, and how a dispute plays out under a process that is separate from the UDRP most resellers know from generic TLDs.



This article covers who can register a .cl domain, what NIC Chile expects from the holder afterward, how .cl disputes work, and how to add .cl to your portfolio through Openprovider.



<h2 class="wp-block-heading" id="h-key-takeaways">Key takeaways</h2>



<ul class="wp-block-list">
<li>Any natural or legal person, Chilean or foreign, can register a .cl domain.</li>



<li>A .cl domain can be registered or renewed for any term from 1 to 10 years, with no forced minimum.</li>



<li>Registrant data has to stay accurate. NIC Chile can delete a domain over incomplete or inaccurate identification data if it is not corrected within five calendar days.</li>



<li>Disputes run through NIC Chile&#8217;s own arbitration process, and the arbitrator&#8217;s decision cannot be appealed.</li>
</ul>



<h2 class="wp-block-heading" id="h-anyone-can-register-a-cl-domain">Anyone can register a .cl domain</h2>



Any natural or legal person can register a .cl domain, whether they are Chilean or foreign. This comes from <a href="https://www.nic.cl/normativa/reglamentacion.html">article 7 of NIC Chile&#8217;s regulations</a>.



One caveat: NIC Chile reserves the right to request proof of the holder&#8217;s identity in exceptional cases, so it is worth making sure the registrant details you submit match the client&#8217;s real identity.



For the wider case on why the Chilean market is worth investing in, see our <a href="https://www.openprovider.com/blog/cl-domain-chile-reseller-guide">Chile reseller guide</a>.



<h2 class="wp-block-heading" id="h-the-importance-of-keeping-registrant-data-current">The importance of keeping registrant data current</h2>



Every .cl registration needs an administrative contact. This contact acts as the holder&#8217;s representative for every regulatory purpose, disputes included, so it needs to be someone who can respond if NIC Chile or a third party gets in touch.



Registration data must be complete and accurate, and the holder is obliged to keep it up to date for as long as they hold the domain. Under article 17 of NIC Chile&#8217;s regulations, incomplete or inaccurate identification data is grounds for deletion. NIC Chile can request a correction by email, and if the data is not fixed within five calendar days, the domain can be deactivated and then deleted.



For a reseller managing dozens of Chilean registrations, that five-day deadline belongs in your data-hygiene process. Weekends count, so a request that arrives on a Friday leaves very little working time.



<h2 class="wp-block-heading" id="h-predictable-cl-pricing-makes-quoting-simpler">Predictable .cl pricing makes quoting simpler</h2>



A .cl domain can be registered or renewed for any term from 1 to 10 years.<a href="https://www.nic.cl/dominios/tarifas.html"> NIC Chile&#8217;s registry price</a> is the same for each year, so the registry cost grows evenly with the number of years the client chooses. The price you pay on top of that depends on your registrar.



That pricing predictability is worth building into how you quote. A client who wants a lower upfront cost can register for a single year. A client who wants to avoid an annual renewal conversation can go longer. Either way, the term is your decision to make with the client.



If a client&#8217;s domains are already spread across several providers, keeping track of individually chosen terms is the kind of detail that gets lost. Our piece on<a href="https://www.openprovider.com/blog/how-fragmented-domain-infrastructure-steadily-erodes-margin-at-scale"> how fragmented infrastructure erodes margin at scale</a> explains why that gap is expensive. Managing .cl in the same<a href="https://www.openprovider.com/resellers/reseller-control-panel"> Reseller Control Panel (RCP)</a> as the rest of your portfolio keeps every term and renewal date in one view.



<h2 class="wp-block-heading" id="h-register-brand-names-early-the-first-30-days-carry-the-most-risk">Register brand names early: the first 30 days carry the most risk</h2>



After a .cl domain is registered, NIC Chile adds it to a public list of new registrations for 30 calendar days. During that time, anyone can ask NIC Chile to cancel the registration if they believe they have a better claim to the name, for example because it matches their company name or brand. They don&#8217;t need to prove that the holder did anything wrong. A revocation request costs CLP 46,000 under<a href="https://www.nic.cl/dominios/tarifas.html"> NIC Chile&#8217;s current fee schedule</a>.



After the 30-day window, the bar rises. A challenger then has to show that the registration is abusive, which means meeting all three of these conditions:



<ul class="wp-block-list">
<li>The domain is identical or confusingly similar to a name or trademark the challenger has prior rights to.</li>



<li>The holder has no rights or legitimate interest in the domain.</li>



<li>The domain was registered or is being used in bad faith.</li>
</ul>



The first month is when a new .cl is most exposed. If a client is registering a brand-related .cl name, it is worth registering it well before launch, so the 30-day window closes before the brand goes public.



<h2 class="wp-block-heading" id="h-how-cl-disputes-work-outside-the-udrp">How .cl disputes work outside the UDRP</h2>



.cl disputes do not use ICANN&#8217;s <a href="https://www.icann.org/en/contracted-parties/consensus-policies/uniform-domain-name-dispute-resolution-policy/uniform-domain-name-dispute-resolution-policy-01-01-2020-en">Uniform Domain-Name Dispute-Resolution Policy (UDRP)</a>, the process most resellers know from generic TLDs. Anyone who believes a .cl registration harms their rights can request revocation under NIC Chile&#8217;s own dispute policy.



The parties can agree on an arbitrator between themselves. If they don&#8217;t, NIC Chile appoints one from a list published on its website. The arbitrator&#8217;s decisions cannot be appealed, a right every registrant waives by holding a .cl domain. For contractual matters outside the arbitrator&#8217;s remit, the parties fall under the jurisdiction of the courts in Santiago.



While a revocation case is open, the domain is blocked: the holder cannot be changed and the domain cannot be deleted. The holder can still update the domain&#8217;s data unless the arbitrator orders otherwise. NIC Chile&#8217;s dispute resolution policy sets out the full procedure.



<h2 class="wp-block-heading" id="h-plan-for-registry-level-suspensions-in-your-abuse-process">Plan for registry-level suspensions in your abuse process</h2>



Since a<a href="https://www.nic.cl/normativa/reglamentacion.html"> 2020 amendment to NIC Chile&#8217;s regulations</a>, the registry can suspend a .cl domain temporarily or permanently if it was registered for phishing, malware distribution, botnet operation, or other technical abuse of the DNS.



For a reseller, this is an action the registry takes directly on a domain you manage and bill for, so your abuse-handling process should account for it.<a href="https://www.openprovider.com/products/security/premium-dns">&nbsp;</a>



<h2 class="wp-block-heading" id="h-choose-who-receives-nic-chile-s-emails-before-you-register">Choose who receives NIC Chile&#8217;s emails before you register</h2>



NIC Chile sends every notification, including the five-day correction request, to the email addresses in the domain&#8217;s registration data. Keeping those addresses working is the holder&#8217;s exclusive responsibility.



If you use your own address as the reseller, you are responsible for anything that gets missed. If you use the client&#8217;s address, make sure someone monitors it, since a missed email does not pause the five-day deadline.&nbsp;



Either approach can work, as long as the choice is deliberate. If the client needs a monitored address, business email can be set up alongside the domain.



<h2 class="wp-block-heading" id="h-what-to-check-before-you-quote-a-cl-domain">What to check before you quote a .cl domain</h2>



A few details decide whether a .cl registration stays trouble-free after the sale, so it&#8217;s worth confirming them with the client before you send a quote:



<ul class="wp-block-list">
<li>The term the client wants, and the total upfront cost for that term</li>



<li>Who holds the contact email, and whether someone monitors it</li>



<li>Whether the registrant details match the client&#8217;s real identity</li>



<li>Whether the client has a Chilean trademark worth defending, given the higher risk in the first 30 days</li>
</ul>



<h2 class="wp-block-heading" id="h-sell-cl-alongside-the-rest-of-your-portfolio">Sell .cl alongside the rest of your portfolio</h2>



With Openprovider, .cl sits alongside more than 2,000 TLDs in one <a href="https://www.openprovider.com/resellers/reseller-control-panel">RCP</a>, so you can register, renew, and manage every client domain in the same place, whether through the panel or the API.



<a href="https://www.openprovider.com/membership-plans">Openprovider Membership</a> gives you cost-price access to Openprovider-accredited TLDs, with no markup added between you and the registry. That leaves more room for your own margin on every domain you sell.



<a href="https://cp.openprovider.eu/signup">Create your free account</a>, no card needed, and try out the platform for yourself.



<h2 class="wp-block-heading" id="h-faq">FAQ</h2>



Can a foreign company register a .cl domain? Yes. Any natural or legal person, Chilean or foreign, can register a .cl domain.



What information do you need to register a .cl domain? You need complete and accurate registrant data and an administrative contact, which is mandatory. The data must be kept current for as long as the domain is registered.



What is the minimum registration period for a .cl domain? There is no forced minimum. A .cl domain can be registered for any term from 1 to 10 years, and the registry charges the same amount for each year.



When does a .cl domain need to be renewed? Before the end of the term you registered it for. Renewals can be for any term from 1 to 10 years, and a domain that is not renewed can be deleted.



Can a .cl domain be deleted for inaccurate contact data? Yes. Under article 17 of NIC Chile&#8217;s regulations, incomplete or inaccurate identification data is grounds for deletion if it is not corrected within five calendar days of NIC Chile&#8217;s request.



Does .cl use UDRP? No. .cl disputes run through NIC Chile&#8217;s own dispute resolution policy, which is separate from ICANN&#8217;s UDRP.



Can someone challenge a .cl domain after it is registered? Yes. Inside the first 30 days, a challenger only needs to claim a preferential interest in the name. After that, they must prove the registration is abusive under a three-part test.



What happens to a .cl domain during a dispute? The domain is blocked. The holder cannot be changed and the domain cannot be deleted, but the holder can still update its data unless the arbitrator orders otherwise.



Can NIC Chile suspend a .cl domain? Yes. Since a 2020 amendment, NIC Chile can suspend a .cl domain temporarily or permanently for phishing, malware, botnet activity, or other technical abuse of the DNS.



Who manages the .cl registry? NIC Chile, which is run by the Department of Computer Science at the University of Chile under delegation from IANA.

cl_1200x628-1

CL_1200x628-1

Auto Draft

Engagement moves through links, and the resellers who offer clients a name worth clicking are the ones who win.



Last time, we covered<a href="https://www.openprovider.com/blog/why-link-premium-domains-are-worth-the-investment"> why .link premium domains are worth the investment</a>. This follow-up turns that case into a sales plan: How to sell .link domains to your customers, which clients to approach, when to offer a premium name, and what to say.



<h2 class="wp-block-heading" id="h-link-premium-domains-for-resellers-at-a-glance">.link premium domains for resellers at a glance</h2>



A premium .link domain is used as a primary brand domain, a campaign landing page, or a branded short link. Resellers sell premium .link domains to new businesses, marketing teams, and companies going through a rebrand. Premium .link names are short and memorable, so customers find them easy to read, say, and type.



Here&#8217;s what this guide covers:



<ul class="wp-block-list">
<li>Why premium .link names work as a standalone brand domain or alongside an existing one</li>



<li>Four client conversations lead naturally to a premium .link sale</li>



<li>Four trigger moments tell you when to offer a premium .link name</li>



<li>Ready-to-use pitch lines help you start today</li>



<li>How to register a .link premium domain</li>
</ul>



<h2 class="wp-block-heading" id="h-four-client-conversations-that-lead-to-a-premium-link-sale">Four client conversations that lead to a premium .link sale</h2>



Premium .link domains suit any business that wants a short, memorable web address, so resellers can offer them across their whole client base. But for the fastest results, resellers should focus first on four types of clients: new businesses and startups, marketing teams and agencies, businesses using generic URL shorteners, and companies going through a rebrand.



The new brand client: a founder naming a new business wants an address that is short, easy to say, and still available. Premium .link names offer exactly those qualities, so they can carry a brand from day one, from the website to business cards and app store listings.



The campaign client: a client planning an event or ad campaign needs an address that works on a poster, in a video, and behind a QR code. A short premium .link name reads cleanly in all three, and it keeps the campaign separate from the client&#8217;s main site.



The short link client: a client sharing links through a third-party shortener puts someone else&#8217;s branding on every click. A premium .link name gives them their own branded root for social posts, newsletters, and sales emails.



The rebrand client: a business changing its name needs an address that carries the new identity. A premium .link name can become the new primary domain, or it can handle launch pages and redirects during the transition.



Each of these clients already has a reason to buy, and you can check available names for them on the<a href="https://www.openprovider.com/domains/tlds/link"> .link page</a>.&nbsp;



To turn that reason into a sale, raise a premium .link name when the client is already thinking about their domain or brand. These opportunities come up more often than most resellers expect, and the next section shows you where to find them.



<h2 class="wp-block-heading" id="h-four-situations-when-clients-are-ready-to-say-yes-to-a-premium-link-name">Four situations when clients are ready to say yes to a premium .link name</h2>



The best time to offer a client a premium domain is when they&#8217;re already making a domain or branding decision. The four trigger moments are the first domain registration, the renewal conversation, a campaign or product launch, and a rebrand. At each of these points, a premium domain fits into a decision the client is already making.



Here&#8217;s how to bring it up in each situation:



<ul class="wp-block-list">
<li>At registration: present a premium .link name as the primary domain, or as a second name for campaigns.</li>



<li>At renewal: ask what the year ahead holds for the client&#8217;s brand.</li>



<li>At launch: offer a premium name before the marketing materials go live.</li>



<li>At rebrand: recommend a premium .link name as the new brand domain.</li>
</ul>



Timing opens the door, and how you package the name decides how easily the client walks through it.



<h2 class="wp-block-heading" id="h-sell-premium-link-names-in-the-way-that-fits-each-client">Sell premium .link names in the way that fits each client</h2>



Premium .link names are flexible enough to sell in whatever way suits the client, and two approaches work especially well. For a new business or a rebrand, the name becomes the main domain, with hosting, email, and DNS built around it. For an established business, the name sits alongside the existing domain as part of a campaign or branded link service.



For example, an agency building a website for a startup can propose a premium .link name as the brand domain and quote it with hosting and email. The client launches with a memorable address, and the agency adds a premium sale and a new renewal to the portfolio.



Premium names carry a higher price than standard registrations, so each sale adds more revenue per client.



With your approach ready, the final step is putting the offer into words your client will respond to.



<h2 class="wp-block-heading" id="h-pitch-lines-to-sell-link-premium-domains-today">Pitch lines to sell .link premium domains today</h2>



Once you know who to approach and when, the right words make the conversation much easier to start.&nbsp;



The lines below give you a starting point for each of the four client types covered earlier. Adapt each one to the conversation you&#8217;re having, whether that&#8217;s an email, a proposal, or a call. Add the client&#8217;s name, their project, or the details they care about most, so the offer feels made for them.



<figure class="wp-block-table"><table class="has-fixed-layout"><tbody><tr><td>Client conversation</td><td>Pitch line</td></tr><tr><td>New brand</td><td>&#8220;We found a short, memorable web address for your new business that customers will find easy to say and type.&#8221;</td></tr><tr><td>Campaign</td><td>&#8220;For this campaign, we can get you a short, memorable web address that works on posters and QR codes.&#8221;</td></tr><tr><td>Short links</td><td>&#8220;Your shared links could carry your own brand, with a short name your customers will recognize and trust.&#8221;</td></tr><tr><td>Rebrand</td><td>&#8220;For the rebrand, we can secure a short address that carries your new name and helps customers find you easily.&#8221;</td></tr></tbody></table></figure>



Each line points toward the same outcome: a premium .link name registered and managed through your Openprovider account.



<h2 class="wp-block-heading" id="h-sell-link-premium-domains-with-openprovider">Sell .link premium domains with Openprovider</h2>



Premium .link names slot into the workflow you already use for every other TLD in your portfolio, with no new registry relationship to set up:



<ul class="wp-block-list">
<li>Registrations, renewals, transfers, and DNS for premium .link names run through the same domain API and Reseller Control Panel as the rest of your catalog</li>



<li>One dashboard and one support line cover .link alongside every other extension you sell</li>
</ul>



Pricing for each premium name is listed on the<a href="https://www.openprovider.com/domains/tlds/link"> .link page</a>. If clients are asking for short, memorable names and your current setup can&#8217;t deliver them,<a href="https://cp.openprovider.eu/signup"> create a free Openprovider account</a> and start selling premium .link domains today.

link_1124x400-2

link_1124x400 (2)

On 2 September 2026, zones on our Premium DNS product stopped resolving. We have published a full incident report covering the timeline, where our own response was not good enough, and the commitments we have made as a result, including replacing the provider.&nbsp;



This post is not that.&nbsp;



This post is about the mechanism, because the mechanism is genuinely interesting, and because most of the explanations circulating during the incident were wrong in the same instructive way.



Here’s the short version of the cause: the upstream provider migrated their own domain infrastructure and did not carry over the address records for their four nameserver hostnames. Not the zones. Not the servers. The address records for the names of the servers.



That distinction is the whole story. The DNS data for every affected domain was intact throughout. The machines serving it were up and answering. What disappeared was the ability of any resolver on the internet to work out where to send the question. It is a failure one level above the one everybody assumes when a nameserver stops working, and it behaves completely differently.



In this blog, we outline the resolution chain that broke, why four nameservers gave no protection, and the commands that would have told you the truth in under a minute.



<h2 class="wp-block-heading" id="h-the-chain-that-has-to-hold">The chain that has to hold</h2>



To answer a query for example.com, a resolver walks down a chain of referrals. The root tells it where .com is served. The .com nameservers tell it that example.com is delegated to a set of nameserver hostnames, in this case four names under a single provider domain. Then &#8211; and this is the step that matters &#8211; the resolver needs an IP address for at least one of those hostnames before it can ask anything.



There are two ways it can get one.



The first is glue. When the parent zone can supply address records for the nameservers alongside the referral, the resolver gets the names and the addresses in the same response and proceeds immediately. This is the common case and it is invisible.



The second is a separate lookup. When glue is absent, expired from cache, or the nameserver names sit outside the zone being delegated, the resolver has to suspend the original query, go and resolve the nameserver hostname as a fresh question from the root down, then come back and resume. This is the out-of-bailiwick case, and it is entirely normal. A large share of the internet&#8217;s domains are delegated to nameservers under someone else&#8217;s domain, which is what happens the moment you use a <a href="https://www.openprovider.com/products/security/premium-dns">managed DNS provider</a>.



Both routes terminate at the same place: address records for those four hostnames. When those records were not carried over during the provider&#8217;s migration, both routes went dark simultaneously. Glue had nothing to supply, and the independent lookup had nothing to find. The resolver reached the point in the chain where it needed an address, found no way to obtain one, and gave up.



<h2 class="wp-block-heading" id="h-why-four-nameservers-protected-nothing">Why four nameservers protected nothing</h2>



Every managed DNS product advertises multiple nameservers, and resellers reasonably read that as redundancy. It is, against one specific failure: a server going down. A resolver that cannot reach ns1 will try ns2, and the outage is absorbed without anyone noticing. That mechanism works well and it’s why single-server DNS failures are rarely newsworthy.



Here, that mechanism provided no protection, because the four nameservers were four names sharing one dependency. They lived under the same provider domain, and their addresses came from the same set of records. When that set went missing, all four names became unresolvable at once. There was no healthy member of the set to fail over to, because the failure was not in any member. It was in the thing all four members were made of.



This is the part worth carrying away from the incident even if you never use this product. Nameserver count is not a measure of redundancy. What matters is whether the nameservers fail independently, and names under one parent domain, maintained as one set of records, by one operator, in one migration, do not fail independently. Four of them is one point of failure with four labels on it.



DNSSEC, for the same reason, would not have helped. Signing a zone protects you against a forged answer. It has nothing to say about the absence of any answer at all.



<h2 class="wp-block-heading" id="h-what-servfail-was-actually-telling-you">What SERVFAIL was actually telling you</h2>



Affected queries returned SERVFAIL, which is one of the least informative things DNS can tell you, and during the incident it sent a lot of people looking in the wrong place.



SERVFAIL does not mean the record is missing. That is NXDOMAIN. SERVFAIL means the resolver was unable to complete resolution and cannot say why in a way that fits in a response code. From the outside, that looked identical to a dozen unrelated problems. The domain was registered and fine. WHOIS was fine. The zone contents in the control panel were fine, and correct. Nothing a reseller could inspect on their own side was broken, which is exactly why several hours of collective debugging went into infrastructure that was never at fault.



Four commands separate this class of failure from the things it resembles. They are worth knowing before you need them.



Start with the trace, which shows you where the chain stops rather than just that it stopped:



dig +trace example.com



Check what the parent actually says about the delegation, so you know whether the NS set itself is intact:



dig NS example.com @a.gtld-servers.net



Then the diagnostic that would have identified this incident in about four seconds. Ask for the address of the nameserver hostname itself:



dig A ns1.your-dns-provider.example



If that fails while your own zone looks healthy, the problem is not your domain and not your records. It is the provider&#8217;s ability to be found. Every affected domain shared that one symptom, and no affected domain had anything else in common.



Finally, if you can get an address for the nameserver from any source, a cached value, documentation, a monitoring system, ask it directly and bypass the naming layer entirely:



dig SOA example.com @198.51.100.53



During this incident, that query answered correctly. The servers were serving the right data for the right zones the entire time. Confirming that is what tells you the outage is in discovery rather than in data, and it changes what you do next, because a data loss and a discovery failure call for opposite responses.



<h2 class="wp-block-heading" id="h-the-blast-radius-ordered-by-how-long-it-hurts">The blast radius, ordered by how long it hurts</h2>



DNS failures are usually described as though everything breaks and then everything recovers. In practice the damage is staggered, and the parts that recover slowest are the parts nobody watches during the incident.



<h3 class="wp-block-heading" id="h-web-traffic-fails-first-and-recovers-first">Web traffic fails first and recovers first</h3>



A, AAAA and CNAME lookups fail, browsers show a resolution error, and the moment resolution returns, so does the site. Recovery is not perfectly simultaneous, because resolvers cache failures as well as successes, and implementations differ in how long they hold a failed lookup. Some clients came back minutes after others.



<h3 class="wp-block-heading" id="h-mail-mostly-defers-rather-than-dies">Mail mostly defers rather than dies</h3>



a sending server that cannot resolve MX gets a temporary failure and queues the message, then retries, typically over a period measured in days rather than minutes, though every sender has its own policy and a minority give up early. So the visible mail loss from an outage like this is small, and the invisible consequence is a backlog that lands later, along with whatever your customers concluded when their mail went quiet for an evening.



<h3 class="wp-block-heading" id="h-email-authentication-fails-in-a-way-that-outlives-the-outage">Email authentication fails in a way that outlives the outage</h3>



SPF, DKIM and DMARC are DNS lookups performed by the receiving side, not by you. A receiver holding your MX in cache but unable to resolve your TXT records will process mail it cannot authenticate. Handling varies: some receivers defer, some treat it as unauthenticated and apply policy accordingly. Either way, the record of it sits in receiver reputation systems after your DNS is healthy again, which is the sort of damage you find out about a week later from a deliverability report.



<h3 class="wp-block-heading" id="h-certificate-issuance-stops-and-that-one-waits-to-bite">Certificate issuance stops, and that one waits to bite</h3>



A CA has to check CAA immediately before issuing, and a CAA lookup that cannot be resolved is not treated as permission. Any issuance or renewal attempted inside the window failed. ACME clients retry, so for most domains this resolves itself invisibly. For a certificate that happened to be close to expiry, it does not, and that failure surfaces days later as an expired certificate with no obvious connection to a DNS incident anyone still remembers.



<h2 class="wp-block-heading" id="h-why-the-per-domain-workaround-did-not-scale-in-ttl-terms">Why the per-domain workaround did not scale, in TTL terms</h2>



The workaround available during the incident was to recreate a zone on our own nameservers and repoint the domain&#8217;s delegation. It works. Our incident report is straightforward about the fact that we had no way to do it in bulk, and that this was our gap rather than the provider&#8217;s.



What is worth adding here is that the manual labour was not the expensive part. The delegation change was.



Rebuilding a zone by hand is tedious and error-prone, and for a portfolio of a few hundred domains it is a serious amount of work. But once you have done it, you change the NS records at the registry, and then you wait, because resolvers that already hold the old NS set keep using it until it expires. Delegation NS records carry long TTLs by design, commonly 48 hours in .com, and varying by TLD. So the domain you fixed at 18:00 is not reliably fixed at 18:05. It is fixed for resolvers with cold caches, and gradually fixed for everyone else.



In this case the provider&#8217;s fix landed at around 02:21. A delegation change made during the evening would in many cases still have been propagating when the underlying problem was already resolved, and then you pay the same propagation cost again to move the zones back. That is the real reason emergency re-delegation is a poor tool for a short vendor outage, and the real reason bulk tooling has to exist before you need it rather than being assembled while the incident is live. It is also why we are building the scripted path now, when the clock is not running.



<h2 class="wp-block-heading" id="h-what-we-take-from-this-structurally">What we take from this structurally</h2>



The provider replacement is covered in the incident report and it is the headline change. The engineering lesson underneath it is the one we would rather other people take away too.



A DNS dependency chain is part of your product&#8217;s failure surface, not the vendor&#8217;s private business. We knew the product depended on four nameservers. What we had not treated as our problem was that those four names depended on one domain, maintained by one operator, whose own infrastructure migration was not something we would ever see coming or be told about in advance. The dependency was documented. Its correlation was not examined.



So the questions we now ask of an infrastructure vendor are different. Not how many nameservers, but whether the nameserver names resolve through independent paths. Not whether they have redundancy, but what single change on their side can take all of it out at once. Not whether they have an incident process, but whether we can operate around them without one.



<h2 class="wp-block-heading" id="h-checking-your-own-exposure">Checking your own exposure</h2>



None of this is specific to one provider, and the check takes a minute.&nbsp;



To see what your domains are actually delegated to, across whatever portfolio you manage:



while read d; do



&nbsp;&nbsp;printf &#8216;%s &#8216; &#8220;$d&#8221;



&nbsp;&nbsp;dig +short NS &#8220;$d&#8221; | sort | tr &#8216;\n&#8217; &#8216; &#8216;



&nbsp;&nbsp;echo



done &lt; domains.txt



Then look at the output with two questions in mind. Do all the nameservers for a given domain sit under one parent domain, and is that acceptable for what the domain does? And can you resolve each of those nameserver hostnames independently right now?



dig +short A ns1.your-dns-provider.example



For domains where the answer to the first question matters, the fix is nameservers whose names do not share a fate. That means more than one provider, with names under more than one parent domain, which is more work to run and is the honest price of the guarantee.



Domains on Openprovider&#8217;s own nameservers were unaffected throughout this incident, and if you want to move zones there, support can help. That is not the point of this post, and it would be a poor lesson to draw from it.&nbsp;



The point is that the four names on your delegation are a dependency worth understanding before somebody else&#8217;s migration teaches it to you.



The full incident report, with the timeline and what we are changing, is <a href="https://lp.openprovider.com/hubfs/Premium%20DNS%20outage.pdf">here</a>.

1124x400_dark-1

1124x400_dark (1)

Business Advice

Business Email

Company Updates

Domain News

Domain Resellers

Domains

Geen onderdeel van een categorie

Industry News

Podcasts

Security

Sin categorizar

SSLs and Security

Tech & AI

TLDs

Uncategorized @hi

Domain transfer

Domain prices

Domain promotions

WHOIS lookup

Reseller control panel

WHMCS

Plesk license

WP Guardian

Other integrations

Business email

Spam filtering

EasyDMARC

Premium SSL certificates

Premium DNS

S/MIME and CodeSigning

Free domain security scanner

Domains & Services

Membership plans to give you competitive advantage

Membership program

Membership pricing

Membership

Web hosting providers

Digital agencies

Marketing agencies

Solutions

Blog

Leadership resources & Media

Cybersecurity Hub

Corporate Social Responsibility

API documentation

Knowledge base

Contact support

Resources

openprovider-blocks/dynamic-blog-hero-highlight

Openprovider Blog

openprovider-blocks/hero-center-with-badge-v2

openprovider-blocks/dynamic-blog-list-categories

Find Your Domain

frame-1000005428

Frame 1000005428

New blog page development

Sign me up!

Become a Member today and get access to exclusive deals.

.cl domain requirements every reseller should know

Openprovider Blog

Not a Member yet?