DNSwas designed in the 1980s when the Internet was much smaller, and security was not a primary consideration in its design. As a result, when a recursive resolver sends a query to an authoritative name server, the resolver has no way to verify the authenticity of the response. The resolver can only check that a response appears to come from the sameIPaddress where the resolver sent the original query. But relying on the sourceIPaddress of a response is not a strong authentication mechanism, since the sourceIPaddress of aDNSresponse packet can be easily forged, orspoofed. AsDNSwas originally designed, a resolver cannot easily detect a forged response to one of its queries. An attacker can easily masquerade as the authoritative server that a resolver originally queried by spoofing a response that appears to come from that authoritative server. In other words an attacker can redirect a user to a potentially malicious site without the user realizing it.
Recursive resolvers cache theDNSdata they receive from authoritative name servers to speed up the resolution process. If a stub resolver asks forDNSdata that the recursive resolver has in its cache, the recursive resolver can answer immediately without the delay introduced by first querying one or more authoritative servers. This reliance on caching has a downside, however: if an attacker sends a forgedDNSresponse that is accepted by a recursive resolver, the attacker haspoisoned the cacheof the recursive resolver. The resolver will then proceed to return the fraudulentDNSdata to other devices that query for it.
As an example of the threat posed by acache-poisoning attack, consider what happens when a user visits their bank’s website. The user’s device queries its configured recursive name server for the bank web site’sIPaddress. But an attacker could have poisoned the resolver with anIPaddress that points not to the legitimate site but to a web site created by the attacker. This fraudulent website impersonates the bank website and looks just the same. The unknowing user would enter their name and password, as usual. Unfortunately, the user has inadvertently provided its banking credentials to the attacker, who could then log in as that user at the legitimate bank web site to transfer funds or take other unauthorized actions.
Engineers in the Internet Engineering Task Force (IETF), the organization responsible for theDNSprotocol standards, long realized the lack of stronger authentication inDNSwas a problem. Work on a solution began in the 1990s and the result was theDNSSECSecurityExtensions (DNSSEC).
DNSSECstrengthens authentication inDNSusingdigital signaturesbased onpublic key cryptography. WithDNSSEC, it’s notDNSqueries and responses themselves that are cryptographically signed, but ratherDNSdata itself is signed by the owner of the data.
EveryDNSzone has apublic/private key pair. The zone owner uses the zone’sprivate keyto signDNSdata in the zone and generate digital signatures over that data. As the name “private key” implies, this key material is kept secret by the zone owner. The zone’spublic key, however, is published in the zone itself for anyone to retrieve. Any recursive resolver that looks up data in the zone also retrieves the zone’s public key, which it uses tovalidatethe authenticity of theDNSdata. The resolver confirms that the digital signature over theDNSdata it retrieved is valid. If so, theDNSdata is legitimate and is returned to the user. If the signature does not validate, the resolver assumes an attack, discards the data, and returns an error to the user.
DNSSECadds two important features to theDNSprotocol:
Data origin authenticationallows a resolver to cryptographically verify that the data it received actually came from the zone where it believes the data originated.
Data integrity protectionallows the resolver to know that the data hasn’t been modified in transit since it was originally signed by the zone owner with the zone’s private key.
Every zone publishes its public key, which a recursive resolver retrieves to validate data in the zone. But how can a resolver ensure that a zone’s public key itself is authentic? A zone’s public key is signed, just like the other data in the zone. However, the public key is not signed by the zone’s private key, but by theparent zone’sprivate key. For example, theicann.orgzone’s public key is signed by theorgzone. Just as aDNSzone’s parent is responsible for publishing a child zone’s list of authoritative name servers, a zone’s parent is also responsible for vouching for the authenticity of its child zone’s public key. Every zone’s public key is signed by its parent zone, except for the root zone: it has no parent to sign its key.
The root zone’s public key is therefore an important starting point for validatingDNSdata. If a resolver trusts the root zone’s public key, it can trust the public keys of top-level zones signed by the root’s private key, such as the public key for theorgzone. And because the resolver can trust the public key for theorgzone, it can trust public keys that have been signed by their respective private key, such as the public key foricann.org. (In actual practice, the parent zone doesn’t sign the child zone’s key directly–the actual mechanism is more complicated–but the effect is the same as if the parent had signed the child’s key.)
The sequence of cryptographic keys signing other cryptographic keys is called achain of trust. The public key at the beginning of a chain of trust is a called atrust anchor. A resolver has a list of trust anchors, which are public keys for different zones that the resolver trusts implicitly. Most resolvers are configured with just one trust anchor: the public key for the root zone. By trusting this key at the top of theDNShierarchy, a resolve can build a chain of trust to any location in theDNSname space, as long as every zone in the path is signed.
Validating and Signing withDNSSEC
In order for the Internet to have widespread security,DNSSECneeds to be widely deployed.DNSSECis not automatic: right now it needs to be specifically enabled by network operators at their recursive resolvers and also by domain name owners at their zone’s authoritative servers. The operators of resolvers and of authoritative servers have different incentives to turn onDNSSECfor their systems, but when they do, more users are assured of getting authenticated answers to theirDNSqueries. Quite simply, a user can have assurance that they are going to end up at their desired online destination.
EnablingDNSSECvalidation in recursive resolvers is easy. In fact, it has been supported by nearly all common resolvers for many years. Turning it on involves changing just a few lines in the resolver’s configuration file. From that point forward, when a user asks the resolver forDNSinformation that comes from zones that are signed, and that data has been tampered with, the user will (purposely) get no data back.DNSSECprotects the user from getting bad data from a signed zone by detecting the attack and preventing the user from receiving the tampered data.
Signing zones withDNSSECtakes a few steps, but there are millions of zones that sign theirDNSinformation so that users of validating resolvers can be assured of getting good data. Almost all common authoritative name server software supports signing zones, and many third-partyDNShosting providers also supportDNSSEC. Usually, enablingDNSSECfor a zone with a hosting provider is quite easy: often it entails little more than clicking a check box.
For a zone owner to deployDNSSECby signing their zone’s data, that zone’s parent, and its parent, all the way to the root zone, also need to be signed forDNSSECto be as effective as possible. A continuous chain of signed zones starting at the root zone allows a resolver to build a chain of trust from the root zone to validate data. For example, to effectively deployDNSSECin theicann.orgzone, theorgzone needs to be signed as well as the root zone. Fortunately, theDNSroot zone has been signed since 2010, and all gTLDs and many ccTLDs are also signed.
There is one more step to completeDNSSECdeployment in a zone: the newly signed zone’s public key material needs to be sent to the zone’s parent. As described earlier, the parent zone signs the child zone’s public key, and allows a chain of trust to be built from parent to child.