With 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:
@marca56 @ErrataRob @danyork There's likely no real world solution to making legal domain interdiction impossible.
— Dan Kaminsky (@dakami) July 1, 2014
“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).