Home / Blogs

Nameserver Operators Need the Ability to “Disavow” Domains

Yesterday’s DDoS attack against DNSimple brought to light a longstanding need for DNS nameserver operators to have an ability to unilaterally repudiate domains from their nameservers.

The domains under attack started off on DNSMadeEasy, migrated off to DNSimple and took up residence there for about 12 hours, causing a lot of grief to DNSimple and their downstream customers. It could have been anybody, as we’ve long intimated: every DNS provider is a logical SPOF unto themselves. The only difference is whether they’ll openly admit it, or lie about it (“no! never happened!”)

A few years ago while at an ISOI conference in Washington, DC I sounded a few people out about the idea of having a registry protocol where nameserver operators could “disavow” or “repudiate” a domain—that is to unilaterally cause a given domain to have it’s root delegation to the target nameservers dropped at the nameserver operator’s dictum. The idea didn’t get a lot of traction.

Every time I see this happening (especially when it happens to us), I see the need for this as more pressing. Last night DNSimple made a request to the target domain’s registrar, Godaddy, to make an emergency change to the domain nameserver delegation and remove the DNSimple nameservers. While they had a sympathetic ear from some Godaddy backchannels, the hours dragged on and the outage persisted and the pain compounded until the domain finally hopped to yet another DNS provider (one I’ve never heard of based out of China), who (surprise!) is now offline as well.

These DDOS target domains are like Typhoid Mary’s of the internet world, in many cases having operated if not a dodgy net presence of some sort, at least mired in a deep shade of grey; they hop from DNS provider to DNS provider hoping to leverage said provider’s built-in DDOS mitigation for their own purposes—leaving a trail of destruction across the internet.

DNS Providers, when they are not the registrar of the domain in question, have few tools to employ to deal with these scows of toxic waste when they come in to port:

  1. find out who the DDOS targets are and block them from getting on your system in the first place, or
  2. failing that, if they do come on they are often non-responsive and seem genuinely puzzled that a DNS provider is unwilling to actively firefight their 60Gig/sec DDoS for the $15 they paid to get on the system. That means you have to get their attention some other way: like wildcarding their DNS to localhost and setting the TTL out to a year—they finally realize they have nothing to gain by sticking around and they move on to some other hapless DNS host.

The pure-play DNS provider segment isn’t large in numbers. I’d be surprised if there were more than 100 of them, but they do end up doing DNS for fairly large, well traveled chunks of the internet. When you add to that the non-registrar web-hosting companies, who are in a similar boat, you start to get a chunk of the internet community that is large enough to warrant this type of mechanism.

I would pay money for this!

Of course I would. Let the root operators start optimizing their roots for carrier class DNS providers and attract nameserver records through value added abilities:

  • Realtime rootzone updates.
  • Ability to repudiate domains as described above.
  • Callbacks—get notified when somebody delegates to your nameservers.
  • Whatever else they can think up—ability to filter and key on whois record contents?

Some enterprising party could even create a new TLD specifically optimized toward hosting nameserver records. Now there’s a reason for a new TLD, nevermind all this vertical branding B.S everybody else seems to be obsessed with.

By Mark Jeftovic, Co-Founder, easyDNS Technlogies Inc.

Filed Under


One method wouldn't involve a new protocol Todd Knarr  –  Dec 2, 2014 7:47 PM

One method wouldn’t involve a new protocol at all: having the registrar “ping” each of the nameservers listed for the domain by querying the SOA record on a regular basis. If the registrar doesn’t get back an authoritative answer for the SOA record, it removes that nameserver from the list and updates things as if the domain owner had removed the nameserver. The registrar can do the same check when the domain owner tries to add nameservers, and refuse to add any nameserver that doesn’t say it’s authoritative for that domain. This shouldn’t be too controversial, since it doesn’t make sense to delegate a domain to any nameserver that can’t answer queries for that domain.

That’d let you re-frame the important part. Instead of having the DNS provider “disavow” or “repudiate” the domain, they only need to ask the registrar to re-verify the delegation of the domain. The standard SOA checks get scheduled for the earliest practical timeslot, and things proceed as usual from there. This can be used both to quickly drop a delegation the DNS provider’s no longer authoritative for, and to quickly fix a broken delegation caused by an error on the DNS provider’s end. It’ll probably get more traction avoiding phrasing it as the DNS provider giving orders to the registrar.

Catch-22 Mark Jeftovic  –  Dec 2, 2014 10:00 PM

The problem here is the one time you really want to be able to do this is often the same time your DNS is down because your nameservers have been DDoS-ed. How can the registry know which domains you've intentionally stopped replying for and which ones you can't reply for? You wouldn't want the registry going ahead and dropping all your domains from the roots because you can't reply to their SOA queries. That's why you would need some explicit out-of-band method to tell the registry "yank the delegation for example.com"

better customer due diligence Dr. James Galvin  –  Dec 4, 2014 4:45 PM

I understand your proposal to be suggesting that if a service provider suddenly finds they don’t like the customer they have they should have the ability to repudiate that customer.

While I have some sympathy for that point of view it feels to me like better customer due diligence before on boarding the new customer would address the specific issue you’re experiencing.

I worry that creating the solution you suggest would create far more opportunities for abuse than would justify the solution.  Even if the DNS provider would “never” be malicious, we have to worry about DNS providers becoming targets of nefarious actors who want to “break in” and gain access to this mechanism to forcibly take your customers offline.

It's unrealistic to expect an online merchant Mark Jeftovic  –  Dec 4, 2014 5:19 PM

It's unrealistic to expect an online merchant to conduct due diligence on every customer to the point where you can screen for this. (This is the same direction LEA are trying to push the entire domain registration process and Registrars are understandably protesting at how utterly unworkable it is) - You can do some automated stuff (which we already do, such as examining the domain name and even keyword analysis of their website) - but it's not like you can put up roadblocks and require human verification and dd on every transaction. The abuse concern is a red herring. Every DNS provider and registrar is already a target for malicious actors trying to do exactly what you describe. If you can break into the DNS host, you can take the customer offline (and worse) whether this exists or not. Adding this capability for nameserver operators doesn't change the math in this respect. There lso exists lower hanging fruit that can be used maliciously on new policies(such as spoofing the new ICANN whois accuracy report emailings).

I agree about the due diligence. The Todd Knarr  –  Dec 4, 2014 6:51 PM

I agree about the due diligence. The worst malicious actors are the ones most capable of using a front that looks clean, so the DNS provider may well not have any clue until the problems start occurring. The abuse concern, though, isn't a red herring. This wouldn't involve breaking into the DNS host, it'd be breaking into the new mechanism the DNS provider uses to drop delegations (taking those domains off-line without needing to compromise the DNS provider). It's already happened, see the use of social engineering to use Amazon's password-recovery channel to compromise the Apple and Google accounts of Mat Honan. That's one of the reasons I suggested the registry do an SOA record check. I'm not so worried about the DNS provider being malicious, they'd lose reputable customers too quickly once word got out and most domain owners would have a breach-of-contract claim to pursue against a target that can't just pull up stakes and vanish overnight.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



New TLDs

Sponsored byRadix

Brand Protection

Sponsored byCSC


Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global

Domain Names

Sponsored byVerisign