No, DNSSEC Would NOT Help Prevent Microsoft’s Seizure Of Domains

DNSSEC badgeWith a great bit of the tech media’s attention this week on Microsoft’s court-sanctioned seizure of 23 domains from dynamic DNS provider No-IP.com, multiple people have asked me if deploying DNSSEC would have helped prevent this seizure of domains by Microsoft. Knowing my advocacy of DNSSEC the people asking the question have seemed to want me to be able to say that yes, they would be protected.  They express the concern that a court somewhere in the world could issue a ruling transferring their domain to someone else – and are seeking some form of technical protection. But the answer is:

No, DNSSEC would NOT help prevent this kind of domain seizure.

DNSSEC does one task extremely well – but it does only this one task:

DNSSEC ensures that the information the operator of a domain[1] put into DNS is the exact same information that a user gets out of DNS when they request info for a domain.

To provide a bit more concrete of an example:

If I enter “www.internetsociety.org” into my web browser, my browser will ask the DNS resolver on my computer for the IP address of “www.internetsociety.org”.  My DNS resolver will query DNS and get back the IP address. Because my local DNS resolver validates with DNSSEC, and because internetsociety.org is signed with DNSSEC, my resolver will verify that the IP address I receive is in fact the one that was entered into DNS by the operator of the “internetsociety.org” domain. If the IP address fails DNSSEC validation, I will not be able to get to the website. With this system, I can be sure that I am indeed reaching the correct web server at that IP address.

The beautiful thing about DNSSEC is that it ensures that I am reaching the correct addresses.  It protects me from being redirected to phishing websites or to other sites that are seeking to do “man-in-the-middle” attacks to, for instance, monitor all my traffic or insert targeted advertising or steal my information.  (This animated video may help explain a bit more.)

DNSSEC allows me to trust that the information entered into DNS for a domain is the same information I am receiving.  Communication can be even more secure by using the DANE protocol with DNSSEC to include in DNS information about the TLS (SSL) certificate that a domain operator wants to use.  This can ensure that when I am connecting to a web server or email server I am using the exact TLS certificate that the domain operator wants me to use.  DANE with DNSSEC adds an extra layer of trust to TLS that can make the Internet much more secure – and people are already using DANE in email, IM, VoIP and more services.

For all of these reasons, DNSSEC is a much needed upgrade to DNS to allow us to trust the information we are receiving back from DNS.  It is critical and will strengthen the Internet and make our communication more secure.

BUT…

… let us go back to my original statement about what DNSSEC does:

DNSSEC ensures that the information the OPERATOR of a domain put into DNS is the exact same information that a user gets out of DNS when they request info for a domain.

Note my emphasis on the “operator” of a domain. This is the key point.

Whoever operates the domain controls the security via DNSSEC of the domain.

And by “operates” I mean that they provide the “authoritative name servers” for the domain.  They ultimately answer all queries for information about that domain.  The entity operating as the DNS authority for a domain controls what IP addresses are provide – and controls what DNSSEC signatures are provided. The operator of a domain can even remove DNSSEC if the domain was previously signed.

The operator of the authoritative name servers for a domain has total control over that domain.

Now, let’s jump to Microsoft’s statement about the domain name seizures where I want to highlight one critical piece:

On June 19, Microsoft filed for an ex parte temporary restraining order (TRO) from the U.S. District Court for Nevada against No-IP. On June 26, the court granted our request and made Microsoft the DNS authority for the company’s 23 free No-IP domains, allowing us to identify and route all known bad traffic to the Microsoft sinkhole and classify the identified threats.

See what happened there?  The court ordered that Microsoft be the operator of the domains in question.  I don’t know the precise mechanics of what happened, but my assumption is that the court ordered the registrars of the 23 domains to change the name servers (“NS records” in DNS-speak) to point to Microsoft’s servers.  They may have in fact transferred ownership of the domains to Microsoft – I don’t know the specifics.

Microsoft Is In Control

The key point is that Microsoft now operates the authoritative name servers for the 23 domains. They control whatever information is put into DNS  for those domains.  This is how they can redirect all traffic to those domains to their own infrastructure where they can scan it and perform other actions.

If the domains were signed with DNSSEC, DNSSEC would ensure that I was getting the correct information for the domains out of DNS.

But it would be the information that Microsoft put into DNS for those domains, because the control has been transferred to them.

DNSSEC secures the integrity of the information coming out of DNS.  It protects the  information from modifications by attackers in the middle.  It does not protect against modifications by the operator of the domain.

The Larger Issue Of DNS Insecurity

This recent case is not alone. Here Microsoft obtained a court order that legally allowed them to seize the domains from the current operators.  But there have been any number of “domain name hijackings” over the past few years that have had a similar mode of operation – someone has obtained control of the operation of a domain name and has redirected requests to a different site.  Sometimes this control has been obtained by attacking the name servers at a DNS hosting providing and compromising the systems. Once the attackers are in the name servers they can modify information for a domain (“zone files”) and cause this new information to be published.  Sometimes the control has been obtained by “social engineering” – tricking the DNS hosting operator into letting the attacker login to the account, or tricking the registrar for the domain into believing that the attacker is now the operator of the domain and transferring control.

Believe me, as a DNSSEC advocate I have jumped every time I see “domain hijacking” in media / social media to see if the new incident might show a solid example of where DNSSEC can help.

Almost always… it is not.   It’s something like a system administrator didn’t update software on a web server and an attacker compromised the system.  Or the attackers convinced the registrar to transfer the operation of the domain to them.

It is attacks on the “weak points” of the DNS: the humans reading the email and granting requests, the servers that aren’t updated, etc.

How DNSSEC Could Help

Now, deploying DNSSEC potentially could help against some of these attacks – specifically the ones where attackers break into systems at a DNS hosting provider.  If the attackers convince the registrar to transfer the domain to them, then they are in total control of the operations of the domain, but if the attackers break into name servers there are a couple of more layers of defense that may help thwart the attack.

Validation Failures

If an attacker broke into a DNS name server and modified the DNS info to have different information and did not (or could not) re-sign the zone with DNSSEC, then any user out there who used a validating DNS resolver would not be able to get to the page.  They would be protected against this attack.  (This is why we need to get DNSSEC validation deployed everywhere.)

Note, though, that if the DNS name servers were set to do automatic signing of the zone files, the attackers may be able to modify the files with their false information and then have their new information signed by DNSSEC.  Again, if the attackers can get control of the operations of the domain, including DNSSEC signing, they can modify the info as much as they want.

DS Record

When a DNS resolver “validates” the DNSSEC signatures on DNS information, it uses a “global chain of trust” that goes all the way up to the root of DNS to ensure that the information has not been compromised.  When a DNS operator signs a “zone” with DNSSEC, the “fingerprint” of the key used in the signing is given to the “parent” zone in the form of a “DS record” (where “DS” is “Delegation Signer”).  So if I am a DNS operator and I sign “example.com”, I would provide a DS record to the DNS operator of “.com” that has a fingerprint of the key I used.  If I signed “example.org”, I would provide a DS record to the DNS operator of “.org”, etc. (More info in this DS record tutorial.)

If an attacker broke into a DNS name server and tried to remove the DNSSEC signatures from a zone file, the existence of the DS record in the parent zone would cause a DNSSEC-validating DNS resolver to realize there was an error and not give the user the bogus information.  The users would be protected against this attack.  (This is why we need to get DNSSEC validation deployed everywhere.)

Similarly, if an attacker were able to get the registrar to change the NS records for the authoritative DNS servers for a domain to point to the attacker’s name servers, but was NOT able to get the registrar to update (or remove) the DS record in the parent zone, then even if the attacker signed the domain with a DNSSEC key, it would not be the key that would match up with the DS record.  People using DNSSEC-validating DNS resolvers would be protected against this kind of attack. (This is why we need to get DNSSEC validation deployed everywhere.)

Of course, if an attacker is able to get the registrar to give them control of the domain, then the attacker can provide a new DS record if the attacker signs with a new key – or can remove the DS record and downgrade the domain to an unsigned state.

DNSSEC, though, can help prevent a number of the potential attacks where an attacker compromises some servers in the infrastructure but does not have total control of the domain.

BUT…

… in this case with Microsoft the transfer of operations of the domain was legally sanctioned by a court in Nevada.  Microsoft assumed total control of the operations of the domains.

DNSSEC would not help users know they are not getting to the original web site. Nor would DNSSEC prevent the transfer in any way.  Nor would really any existing technical solution.  This issue goes outside the technical realm and into the legal/political realm.  As Dan Kaminsky himself said in a tweet:

“There’s likely no real world solution to making legal domain interdiction impossible.”

This is a space where we in the technical community must defer to our peers in the legal and public policy communities – or get involved directly in those communities – as our existing technical solutions offer no help here.


[1] To be completely accurate I should technically talk about a “zone” versus a “domain”. In DNS-speak, you operate a “zone” and serve out (and sign) “zone files”. I do realize that… but I am trying to keep this article aimed at more non-technical audiences for whom the domain/zone nuance is not clear.


UPDATE #1 – There is a good discussion of this article happening over on Hacker News (as well as in the comments below).

July 2nd, 2014 by | Posted in DNSSEC | Tags: | 8 Comments

8 Responses to No, DNSSEC Would NOT Help Prevent Microsoft’s Seizure Of Domains

  1. Jim Fenton says:

    Good description of what DNSSEC does and doesn’t do, Dan. But one nit:

    “Whoever operates the domain controls the security via DNSSEC of the domain.
    And by “operates” I mean that they provide the “authoritative name servers” for the domain.”

    I operate the authoritative name servers for my DNSSEC-signed domain. Yet I don’t really have full control: my domain registrar, if compelled by the courts (for example), could change the authoritative name servers and DS records for my domain. It’s something that some operators, particularly in ccTLDs ruled by oppressive regimes, should keep in mind.

    • Dan York says:

      Jim,

      Thanks… and yes, I agree with your nit. This goes back to the distinction between the roles played by a DNS hosting operator and that of a registrar. I debated whether I should get more into this in the article… but it was feeling rather long already. Maybe I should, though. Thanks for the feedback.

      Thanks,
      Dan

  2. Greg Slepak says:

    So much is incorrect in this article.

    > Nor would really any existing technical solution. This issue goes outside the technical realm and into the legal/political realm. As Dan Kaminsky himself said in a tweet:

    Dan is wrong. See my reply to him: https://twitter.com/taoeffect/status/484399595481739265

    > DNSSEC does one task extremely well – but it does only this one task:

    Even this is not true. DNSSEC is an abysmal protocol. To quote from [1]:

    > DNSSEC suggests a complicated mechanism to essentially re-create many of the
    same problems with X509 and CAs in DNS itself, by providing a chain of trust
    to untrustworthy entities. Its intended goal is to secure DNS and thereby
    assure clients that when they ask for apple.com, they are actually visiting
    apple.com. This proposal does not protect against MITM attacks [2]. It suffers
    from extreme and unnecessary complexity, a systemic fault that’s antithetical
    to secure systems. See also this list of resources on why DNSSEC is considered
    harmful [3].

    [1] http://okturtles.com/#oktvs

    [2] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe

    [3] http://ianix.com/pub/dnssec-outages.html

    • Dan York says:

      Greg, Thanks for commenting! I love being challenged. I also replied to you over on HN.

      > So much is incorrect in this article.

      I love it when a comment starts that way. :-)

      > Dan is wrong. See my reply to him: https://twitter.com/taoeffect/status/484399595481739265

      And I see the discussion that ensued. I think we are probably in violent agreement that there are always tradeoffs. It’s just a question of what level of tradeoffs you are willing to accept.

      With regard to your other comments, obviously I don’t think of DNSSEC as “abysmal”. :-) I think it is a solid mechanism for solving the integrity issue with DNS. As you may have seen over on HN, I took issue with your statement:

      > This proposal does not protect against MITM attacks [2]
      > [2] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

      To quote what I posted on HN: Unless I am missing something (which could be), the article you reference as “[2]” does not seem to support the idea that DNSSEC doesn’t protect against MITM attacks. The mentions specifically how DNSSEC and DANE can protect against those attacks, although the article then discusses the author’s issues with trusting the parties involved in the chain of trust.

      For my part, I like the mechanism provided by DANE/DNSSEC because it puts me, as the DNS operator, in control of what TLS cert I want to publish. I can publish my own self-signed cert. I can publish a CA-signed cert (or a fingerprint). I can say that I only support TLS certs from a specific CA. I can designate my own trust anchor for the TLS certs coming from my site. I can publish those certs (or fingerprints) in TLSA records and have them then validated up the global chain of trust. I like how the system is put together.

      > See also this list of resources on why DNSSEC is considered harmful [3].
      > [3] http://ianix.com/pub/dnssec-outages.html

      Yes, this site has been around for quite a long while chronicling seemingly every negative mention of DNSSEC or any time there is an issue or outage. It and other similar sites are actually quite helpful right now while we are still in the relatively early phases of DNSSEC deployment in that they help shine light on what needs to be addressed.

      While DNSSEC adds a level of trust and security to DNS answers, it does add in operational deployment challenges. Some of these have been captured in documents such as RFC 6781 ( http://tools.ietf.org/html/rfc6781 ) and a draft on DANE operational practices ( http://tools.ietf.org/html/draft-ietf-dane-ops-04 ). There will be teething pains as deployment continues. People will forget to upload DS records to their registrar (something a couple of drafts in the DNSOP Working Group are aiming to address). The mechanism for securely transferring a signed domain between DNS hosting operators is still being finalized (see http://tools.ietf.org/html/draft-ietf-eppext-keyrelay-00 ).

      There will continue to be these kind of issues identified as the deployment continues. The good news is that all the people that think DNSSEC is terrible will continue to point them out if we somehow miss seeing them ourselves. :-)

  3. Greg Slepak says:

    Dan, two quick notes (as I’m out of time, must ready okTurtles demo for EFF CUP):

    1. As you’ll note, Kaminsky *was* wrong. The reply thread discusses a different topic.

    2. As for why DNSSEC doesn’t stop MITM, Thomas Ptacek (@tqbf) thankfully saved me the time of having writing another response, which you can read here:

    https://news.ycombinator.com/item?id=7979015

    Also, @moxie does show how DNSSEC would make internet security worse in that post, especially in the video followup that he links to at the end (check out his map in that video of how DNSSEC enlarges the number of actors able to tamper with the system).

    • Dan York says:

      Greg,

      Best wishes with your demo! I think what you are doing with DNSChain and what @moxie is doing with Convergence are very cool efforts!

      Replying:

      1. I guess I understand that in your view when Kaminsky says “There’s likely no real world solution to making legal domain interdiction impossible” he is wrong because of DNSChain. Sure, on a purely technical level you are right. There are solutions such as yours that could make this possible. But the challenge is getting something deployed on a global level. I’m a long-time PGP/GPG user (F7E3C3B4) and have tried in so many ways over the years to see what could be done with that to make email and other systems more secure… but where are we with that? I want to work to make the existing Internet infrastructure more secure and strengthened against attacks. Simultaneously, I’m also always hoping that someone (perhaps you) will come up with even better systems that can be globally deployed.

      2. Yes, he and I are currently engaged in a further discussion: https://news.ycombinator.com/item?id=7979097

      Sadly, I don’t have 45 minutes to watch @moxie’s talk… but I do definitely agree we need to move beyond Certificate Authorities. Hence my interest in DANE/DNSSEC. :-) I do find the work on Convergence to be quite intriguing.

      Thanks for challenging my points. Hope your demo goes well!

      • Greg Slepak says:

        > I’m a long-time PGP/GPG user (F7E3C3B4) and have tried in so many ways over the years to see what could be done with that to make email and other systems more secure… but where are we with that?

        The reason, I think, it’s taken so long to make GPG usable, is because there was no system for securely asking: “What is @dan’s public key?”

        Thanks to Bitcoin, Namecoin, and other blockchain’s, that’s all changed. Now we just need to take advantage of this technology, and what you see on okturtles.com is a vision of what’s possible (simple, secure communication over almost any website, that’s almost as easy as my typing in this text box right now).

        > Thanks for challenging my points. Hope your demo goes well!

        Thanks Dan! :)

        • Dan York says:

          > The reason, I think, it’s taken so long to make GPG usable, is because there was no system for securely asking: “What is @dan’s public key?”

          I think that’s one reason, although I trusted the key servers we all used 10 years ago. (And I’d note there is a proposal to use DNS/DNSSEC as a means of storing PGP keys – http://tools.ietf.org/html/draft-wouters-dane-openpgp-02 ).

          I think the larger reason is that the user experience has historically been so poor on PGP/GPG implementations that it was just hard for non-geeks to really make use of it. I remember trying to help people get setup with GPG for email and it was challenging. I would hope that has gotten better over the years but haven’t honestly looked in a while.

          > Thanks to Bitcoin, Namecoin, and other blockchain’s, that’s all changed. Now we just need to take advantage of this technology

          I would suggest rephrasing that to “Now we just need to ensure this technology can be easily deployed.” That’s the trap so many technologies fall into. People come up with brilliant ideas… but they aren’t easily deployable. And to be “easily deployed” the technology needs to have a super simple user experience to set up and use – and ideally needs to have a business case that may motivate people to install it.

          Note that I’m not necessarily putting DNSSEC into that category. :-)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>