By Varun Narayana Murthy
DNS is absolutely critical foundational to the internet today and one of the issues with DNS is it was designed like back in 80’s, I mean it’s been around for a long time or as the technology goes it’s a long time but it wasn’t designed with security in mind. Since there was no security, attackers were easily able to redirect DNS queries to rogue servers and steal credentials and other important user information. This introduced the need for DNSSEC. What DNSSEC does is, it validates DNS queries. This way the client knows that he is talking to the correct person. DNSSEC adds a layer of trust on top of DNS but also introduces new vulnerabilities to the DNS space. One of the main vulnerabilities of DNSSEC is zone content exposure. This is because of a new record introduced by DNSSEC called NSEC record. Normally as a security measure System administrators will turn off zone transfers while configuring DNS, but if DNSSEC is enabled it subverts this policy.
2.1 Working of DNS
Suppose you want to look at the website http://www.example.com, you go to your browser and type the URL, within a fraction of a second after you pressing enter, your machine tries to find out the IP address that goes with the logical name you’ve typed. Your computer asks the recursive DNS server what IP address the website http://www.example.com can be found at. The recursive DNS server is often the DNS server setup in the Enterprise environment or the DNS server of the Internet Service Provider. Within a split second the recursive DNS server searches its cache for the answer, if it doesn’t have the answer it has to refer the question on. The recursive DNS server accordingly asks the root server, do you know http://www.example.com. The root server looks in it’s zone files but the answer isn’t there either, however the root server does know the address of the zone file for .com is located in. Now the root server refers the query to .com top level domain (TLD). The root server sends back the IP address of the .com TLD to the recursive DNS server. The recursive DNS server then sends the question to the .com TLD DNS server which in turn looks in it’s zone file. Like the root server the .com DNS server is unable to give a precise answer but knows the address of the DNS server the zone file for http://www.example.com is kept on. The .com TLD sends the relevant information back to the recursive DNS server. The recursive DNS server sends out the same question once more, this time to the example.com DNS server. This server looks in it’s zone files and finds the answer your computer’s been looking for, the answer is sent back to the recursive DNS server. The recursive DNS server forwards the answer straight back to your system. The system now knows where http://www.example.com is located and tries to contact the web server at the IP address it’s been given. In response the web server sends back the website content, thus the link between logical name and IP address is completed. After completing the process the recursive DNS server will cache this information so that if somebody else ten minutes later asks the same the question, it doesn’t have to go through the entire process again.
Fig 1 : DNS Resolution process
2.2 Working of DNSSEC
DNSSEC adds security to DNS resolution by introducing cryptographic signatures to the existing DNS records. It uses Asymmetric cryptography. In DNSSEC the domain name is resolved in the same way as described above, except in step 7 example.com DNS server not only sends the IP address but also the DNS key and it’s associated digital signatures. In order to make sure that the response received by recursive DNS server hasn’t been tampered within transit the response is checked for authenticity and validity. The validity checks are made by recursive DNS server. Now the recursive DNS server asks for the hashed public key (DS record) held by the parent zone for http://www.example.com. In our example the parent zone for example.com is .com TLD DNS server. The DS record is looked up in the .com zone files and sent back to the recursive DNS server. The recursive DNS server checks whether the hashed public key (DS record) and the public key from the zone file are the same. If both the keys match the same private key the process proceeds otherwise an error message is sent back to the client. Next the recursive DNS server uses the verified public key to check whether the digital signatures are correct. During this process the recursive DNS server also makes sure that digital signatures are still valid, like whether the current date or time is between the start and end date or time of the specified validity period. Once the checks on example.com are complete the recursive DNS server follows the same procedure for the .com domain. The DNSSEC data for .com domain are verified using the hashed public key (DS record ) obtained from the root server. Again the same process repeats for .com domain as well. This process is often referred as “chain of trust”. Finally after DNSSEC data from the root is verified, this enables the recursive DNS server to conclude that the DNS data has not been tampered with in transit.
Fig 2: Working of DNSSEC
- DNS Records
One of the most important feature of DNS is that it stores data in form of records. DNS records are just mapping files which contains information about which IP address is associated with each domain. The following are a few of the most commonly used DNS records which we encounter in our daily life.
Host (A and AAAA): The A record and Quad A record is one of the most widely used DNS record. It stores the IP address for the corresponding domain names. A record is used for IPv4 and Quad A is for IPv6 addresses.
Alias (CNAME): This record creates an alternative record or alias for another record also called as Canonical name (CNAME)
Mail Server (MX): An MX record identifies the mail server for that particular domain.
Service Record (SRV): A service record indicates the location of a specific services. This record contains information about the service, target (IP address of the host which offers the service), port number and priority.
SOA Record: Only one per zone and contains information about the primary name server for that zone.
Name Server (NS): Contains information about the authoritative DNS servers for that domain.
Pointer (PTR): This record provides a mapping between an IP address and a name. This is exactly opposite of an A or Quad A record.
- DNSSEC Records
Enabling DNSSEC for a zone introduces the following records to the zone files.
RRSIG: This record contains signature for a record set (RRSET). DNS resolvers verify this signature by using the public key which is stored in DNSKEY record.
DNSKEY: Contains the public key which is used to verify RRSIG.
Delegation Signer (DS): The DS record is always placed in the parent zone and contains a reference to the DNSKEY record which is the hash of DNSKEY.
NSEC (next secure record) : An NSEC record links to the next record in the zone. It is used to verify the non-existence of a record in the zone.
NSEC3: It is the same thing as NSEC, but the hashed version.
When you query a DNS server for a specific type of record, say A record for example.com, it replies back with a set of A records that is existent on the server.
The set of all records of a particular type for a domain is called an RRSET
Fig 3: RRSET
To sign these RRSET, RRSIG is used. RRSIG is essentially a digital signature for RRSET.
Fig 4: RRSIG
There are 2 types of DNSKEY records.
Zone Signing Keys (ZSK): Used to sign zone records
Key Signing Keys (KSK): Used to sign DNSKEY records
Zone Signing Key (ZSK):
Zone Signing key is used to sign all types of RRSETs in a DNS server except the DNSKEY RRSET. The private key of ZSK is used to sign the RRSET records and the public key will be stored in one of DNSKEY records. So whenever a DNS resolver asks for a particular record, the DNS server also returns its corresponding RRSIG and DNSKEY records. Now the resolver has the public key of the RRSIG record, it can verify the authenticity of the record.
Fig 5: ZSK verifying a RRSET
Key Signing Key (KSK):
Key signing key is only used to sign the DNSKEY RRSET record. The signing process takes place similar to ZSK. The private KSK is used to sign the DNSKEY RRSETs and the public KSK is stored in another DNSKEY record.
Fig 6: KSK verifying ZSK
4.3 Delegation Signer (DS)
Now as we’ve seen above KSK is used to verify ZSK. Since KSK is signed by the same domain we need somebody to vouch for KSK. This is where Delegation Signer (DS) comes into picture. DS record is hashed value of public KSK and is stored one level above the current domain. For example the DS record for example.com domain will be stored in .com authoritative server. So whenever a DNS resolver queries a child domain the parent domain also replies back with the DS record. Now the resolver has both public KSK and hashed public KSK. The resolver hashes public KSK and compares it with the hashed public KSK that it got from the parent domain. If there is match the packet is not tampered in transit otherwise the DNS resolver sends a warning message back to the client. This is how DNSSEC establishes chain of trust.
Fig 7: DS record verifying KSK
When a DNS authoritative server receives a request for which there is no record on the server, it replies back with a return code NXDOMAIN, which means that there is no records for the requested query. These non-existent replies are unauthenticated and could be forged by an attacker. DNSSEC solves this problem by introducing a new type of record called Next Secure Record (NSEC). NSEC record expresses what names exists and what type of records reside at each name. NSEC records is used to cover gaps between domains in a zone. NSEC records are signed just like any other RRSET with RRSIG. Hence NSEC allows authoritative DNS servers to reply with signed response for any question. Unfortunately this feature of NSEC introduces new vulnerability to DNS space. It allows anybody to walk through the zone and gather information about all the records that is existent within the zone.
Let’s take a look at practical demo of Walking the zone.
I’m choosing http://www.arin.net domain for this demo. American Registry for Internet Numbers (ARIN) is responsible for distribution of Internet numbers including IPv4 and IPv6 address space for the entire United States, Canada, Caribbean and North Atlantic Islands.
Now let’s try to attempt a zone transfer from arin.net domain. For that we need to know the names of the name servers of authoritative arin.net domain.
Using the tool dig I’ll query the ns records for arin.net domain.
As we can see there are 4 name servers for arin.net domain. Now I’ll try to attempt zone transfer on ns1.arin.net name server.
As expected the transfer failed, because as a security measure the system administrator would have turned off zone transfers. Good for them.
Now I’ll query for A records from http://www.arin.net domain.
We can see that there are 2 A records for http://www.arin.net. How do we know that the records returned are not tampered in transit or in other words the IP address returned might be spoofed by an attacker. This is where we need DNSSEC records. Let’s query DNSSEC signatures for A records of www.arin.net.
We can see that the query returned RRSIG record which is the signature for the A RRSET, signed by private ZSK of http://www.arin.net name server.
As we all know the public ZSK will be stored in DNSKEY record. Let’s query the DNSKEY record for arin.net domain.
The query returned DNSKEY record which contains the public ZSK and also the RRSIG for the DNSKEY RRSET.
The RRSIG for DNSKEY RRSET is signed by private KSK and the public key of KSK will be stored in another DNSKEY RRSET on the same server and the hashed version of public KSK will be stored as DS record in the parent domain of http://www.arin.net i.e arin.net
Now let’s query the DS record for arin.net domain.
The query returned the DS record and it’s corresponding RRSIG for the DS RRSET and this RRSIG is verified with the DNSKEY that is stored in net. authoritative TLD. The same process repeats for the net. DNSKEY and DS RRSET which is verified by the DNSKEY stored in the root server. This is how DNSSEC establishes chain of trust.
Now let’s get back to the zone content exposure that DNSSEC introduces to the DNS space.
I’ll query for some random zone name say abuelo.arin.net. It’s highly unlikely that there is a zone record for abuelo in arin.net domain. Nevertheless let’s try it out
As we can see there is no resource records for abuelo.arin.net, but look at what NSEC record is doing. It says the requested zone record doesn’t exist but these are the before and after records of abuelo.arin.net that exists. We can also see that the zone names are ordered alphabetically.
Now I’ll query ac1.arin.net
Look at what NSEC says, ac1.arin.net doesn’t exist, but ac.arin.net and aloe.arin.net are the before and after zones.
Now I’ll query for aloe1.arin.net zone record.
Similarly aloe1.arin.net does not exist, but aloe.arin.net and analytics.arin.net is the before and after zones.
By using this method we can walk through all the zone files in the arin.net domain. In the beginning we saw that the zone transfer failed because it was disabled by system administrator. But using the above method we are able to walk through all the zone files in the arin.net domain. Hence by the above experiment we can see that DNSSEC introduces new vulnerabilities to DNS space.
One can prevent the zone content exposure caused by NSEC record by using NSEC3 record which is the hashed version of NSEC. Let’s take another example say icann.org and query the zone records for abuelo.icann.org.
As we can see the query returned the hashed before and after zone names for abuelo.icann.org. Hence by using NSEC3 records we can prevent the zone content exposure introduced by NSEC records.
We cannot feel safe using NSEC3 records as well because NSEC3 record is the hash of a hostname, usually the length of a hostname will be like 3-10 characters and since the input length to the hashing algorithm is very low, the computed hash can be easily broken using brute force, rainbow table, dictionary attacks etc.
To put it in other words NSEC is like a plaintext password file and NSEC3 is like hashed password file. Given the plethora of tools available today we will be easily able to break the hashed NSEC3 because of it’s low character input to the hashing algorithm. Neither NSEC nor NSEC3 is secure.
To prevent this vulnerability RFC 4470 and 4471 suggests new method called “DNSSEC White lies”. In this method when the DNS servers receives a query for a domain that is not existent in the zone, instead of returning the hash of the next real domain, an NSEC3 record of the next hash is alphabetically returned. This will break the continuity of walking the zone.
DNSSEC adds a layer of security to DNS. But along with security DNSSEC has also introduced new vulnerabilities to DNS space. As we saw NSEC and NSEC3 are neither a good choice to prevent zone content exposure. The RFC 4470 and 4471 suggests a new method to prevent zone content exposure, but in order to implement this method we need to define epsilon functions that generate preceding and following domain names. And also this method requires DNS servers to generate signatures on the fly which will computationally conserve CPU resources. With all these complexities and vulnerabilities introduced by DNSSEC, I would say with due diligence and smart operational practices the vulnerabilities and complexities introduced by DNSSEC can be mitigated.
8) RFC 4033,4034,4035,4470,4471