DNSSEC Explained
The Domain Name System Security Extensions provide cryptographic authentication to prevent redirection to rogue websites, but owners of many domains have yet to adopt it.
DNSSEC Definition
The Domain Name System Security Extensions (DNSSEC) is a set of specifications that extend the DNS protocol by adding cryptographic authentication for responses received from authoritative DNS servers. Its goal is to defend against hackers' techniques to direct computers to rogue websites and servers. While DNSSEC has already been deployed for many generic and country-level top-level domains (TLDs), adoption at the individual and end-user levels has yet to catch up.
What is DNS Spoofing and Hijacking?
In 2008, security researcher Dan Kaminsky discovered a fundamental flaw in the DNS protocol that impacted the most widely used DNS server software. The flaw allowed external attackers to poison the cache of DNS servers used by telecommunications providers and large organizations and force them to serve rogue responses to DNS queries, potentially sending users to spoofed websites or rogue email servers.
That flaw was patched in the most significant coordinated IT industry response to a security vulnerability up to that time, but the threat of DNS hijacking attacks remained. Since DNS traffic was not authenticated or encrypted, any attacker taking control of a DNS server in a user's DNS resolution path could serve malicious responses and redirect them to a malicious server -- a man-in-the-middle scenario.
DNS is like the Internet's phone book. It allows computers to convert human-readable domain names into numerical Internet Protocol (IP) addresses they need to communicate since core networking protocols use IP addresses, not host names.
The Domain Name System has a hierarchical structure with 13 server clusters at the top that manage what is known as the root zone, then servers for each top-level domain (TLD) like .com or .net or country-code TLDs like .us or .ca, then servers for each particular domain name like google.com, then maybe separate servers handling particular subdomains like cloud.google.com.
Every time a client, such as a computer or a device, makes a query, this hierarchy is traversed from the top until the authoritative DNS server for the queried hostname is located and responds with the IP address. However, to improve the performance of DNS, responses can be cached for some time in servers along the path. Most devices will not query the root zone themselves but will query a local DNS server that acts as a resolver, which might query another DNS resolver. For example, home routers typically act as a DNS resolver and the first hop in the DNS chain for all computers and devices on the local network. Routers also typically forward requests to DNS resolvers operated by the customer's ISP.
Understanding how DNS works is essential because any server in that chain can be a weak link and a point from where attackers can serve rogue responses. Some malware changes the DNS settings on computers to use DNS servers operated by attackers, in which case the users of the infected computers will be affected. Mass attacks have compromised the DNS settings on home routers, known as router pharming, affecting all users of the networks served by those routers. Other attacks compromise an ISP's DNS resolvers, in which case all of the ISP's customers who rely on those servers could be affected.
Enter DNSSEC
DNSSEC was designed to address those risks and provide cryptographic verification through digital signatures that can be used to validate that records delivered in a DNS response came from the authoritative DNS server serving the queried domain name and haven't been altered en route.
Like Transport Layer Security (TLS) and other secure communication protocols, DNSSEC relies on public key cryptography. Each authoritative name server has a vital pair of private and public keys that is cryptographically linked. The private key is used to sign record sets in a zone, and the signature is published as a DNS record. The public key can validate and store the signature in a DNS record.
How do resolvers ensure the signature and the public key came from the real authoritative name server and not a man-in-the-middle attacker? They go higher up in the hierarchy chain to the parent zone of the child zone whose signature they want to validate. For example, the .com zone is the parent of the google.com zone and the. (root) the zone is the parent of the .com zone.
Another private and public-private key pair that DNS servers use is the key-signing key (KSK). The private KSK key is used to sign the public key from the first pair used to sign records. The public part of the KSK is then given to the parent zone, which publishes it as part of its records for the child zone and is essentially used to authenticate that the information presented in the child zone is valid.
To summarize, a DNS resolver uses a name server's public key to check that the records it provides are signed with its corresponding private key. It then makes sure that the public key presented by the server in the first place is legitimate by looking at another record that contains a signature of that key and compares it with a record from the parent zone -- called a DS record -- to validate it. This establishes a chain of trust between parent and child zones.
If you go higher and higher in the chain, which validates the topmost key pair used to sign the Internet's root DNS zone? The root key pair is generated in a hardware security module kept in a secure location and is rotated periodically in a public and highly audited ceremony involving trusted community representatives worldwide. There is also a critical recovery process in the event of a significant catastrophe where several individuals known as Recovery Key Share Holders need to come together in the same place and use cryptographic tokens to reconstruct the key.
DNSSEC Deployment and Adoption
APNIC, the Internet registry administering IP addresses for the Asia-Pacific region, has a project monitoring DNSSEC validation worldwide. According to the latest statistics, the global rate of DNSSEC validation is around 26%, but validation rates vary significantly by country and region. The US has a DNSSEC validation rate of 30%, Canada only 17%, Western Europe 46%, Eastern Europe 26%, and Africa and Asia around 24%. In some countries, however, DNSSEC validation is over 90%.
When you look deeper into the data, you discover that in parts of Asia, for example, the dominant ISPs chose to just forward DNS queries to Google's Public DNS resolver instead of running their local DNS servers, Dan York, leader of the Internet Society's Open Standards Everywhere project, tells CSO. In other regions, large ISPs have decided to turn on DNSSEC validation on their DNS resolvers in recent years, for example, Comcast in the US, he says.
DNSSEC deployment has many layers. It started with the generation of the first root key pair in 2010, but then the key pair was updated in a rollover process that took several years to plan and execute and was finalized in October 2018. The public part of the key pair had to be shared with internet service providers, enterprise network administrators, DNS resolver operators, DNS resolver software developers, system integrators, and hardware and software distributors, which was a lengthy process. The TLDs and ccTLD operators also had to generate and deploy their keys and processes to enable DNSSEC for their respective DNS zones. Then there's the issue of individual domain owners choosing to sign their records.
"Deployment is moving on," York says. "I think there was a pause between 2015 and 2018 while we waited around for changing the root key, where people running the DNS infrastructure wanted to wait and see how the root key rollover would go. It was completed in 2018, and all things are good; the lights are green, and we're seeing how DNSSEC deployment is going up in the charts."
There are some challenges, especially in the enterprise space, according to York, when it comes to signing their domains and rotating keys. In cases where the domain registrar is also the DNS provider and maintains the authoritative servers for a domain, they can do the signing automatically and transmit the signature records to the TLD to establish the chain of trust, so the process is pretty seamless. However, enterprises tend to run their DNS servers or use content delivery networks or DNS providers that are not also registrars. They need to handle this process themselves.
"When you sign a domain, you must give this little record -- a DS record -- to the TLD registry -- .org, .com, .bank, etc. It's part of this chain of trust that verifies your domain is signed," York says. "The challenge with many enterprises is that they want to go and sign their records .., but then they have to make sure that when their signing key gets changed, it gets communicated to the TLD. Usually, they only have to do that once a year, but this is one part that some enterprises find a little clunky."
There have been incidents in the past where websites became unavailable because of DNSSEC misconfigurations or expired records -- the NASA and HBO Now websites are two examples. By comparison, the TLS/SSL industry and Certificate Authorities have managed to automate some processes involving certificate and key rotations. "It's something enterprises have to think about a bit," York says. "There's some work underway. Some standards allow people to do this. They just have to understand that these things exist."
Also contributing to DNSSEC deployment, according to York, is the increased adoption of DANE (DNS-based Authentication of Named Entities). This protocol relies on DNSSEC records to bind TLS certificates to domain names, telling clients exactly which TLS certificate they should accept for a particular server. This is meant to prevent TLS interception, where a proxy sitting between a user and server can terminate the TLS connection and serve it back to the user with a different certificate. It also makes it possible to use and trust certificates announced by a domain via DNS and cryptographically signed with DNSSEC, even if they haven't been issued by a publicly trusted Certificate Authority (CA).
"This hasn't taken off in the browser space, largely because extra checks are involved, and browsers are focused on performance and speed, but where it has come into play is with secure email," York says. "There's a growing number of people using DANE, signed by DNSSEC, to secure encrypted email from email server to email server. That's an interesting aspect, and it's something enterprises can look at: Is this a way to make their email more secure by providing these kinds of records for their email servers?" York thinks we won't see DNSSEC adoption explode as we did with TLS, especially HTTPS, after Google and other large tech companies put their power behind it and made it default and mandatory for different services and applications. It will likely be slower growth as more ISPs begin to understand the value of using it to check things, and it gets added and turned on in more and more tools, devices, and applications.
DNSSEC Definition
The Domain Name System Security Extensions (DNSSEC) is a set of specifications that extend the DNS protocol by adding cryptographic authentication for responses received from authoritative DNS servers. Its goal is to defend against hackers' techniques to direct computers to rogue websites and servers. While DNSSEC has already been deployed for many generic and country-level top-level domains (TLDs), adoption at the individual and end-user levels has yet to catch up.
What is DNS Spoofing and Hijacking?
In 2008, security researcher Dan Kaminsky discovered a fundamental flaw in the DNS protocol that impacted the most widely used DNS server software. The flaw allowed external attackers to poison the cache of DNS servers used by telecommunications providers and large organizations and force them to serve rogue responses to DNS queries, potentially sending users to spoofed websites or rogue email servers.
That flaw was patched in the most significant coordinated IT industry response to a security vulnerability up to that time, but the threat of DNS hijacking attacks remained. Since DNS traffic was not authenticated or encrypted, any attacker taking control of a DNS server in a user's DNS resolution path could serve malicious responses and redirect them to a malicious server -- a man-in-the-middle scenario.
DNS is like the Internet's phone book. It allows computers to convert human-readable domain names into numerical Internet Protocol (IP) addresses they need to communicate since core networking protocols use IP addresses, not host names.
The Domain Name System has a hierarchical structure with 13 server clusters at the top that manage what is known as the root zone, then servers for each top-level domain (TLD) like .com or .net or country-code TLDs like .us or .ca, then servers for each particular domain name like google.com, then maybe separate servers handling particular subdomains like cloud.google.com.
Every time a client, such as a computer or a device, makes a query, this hierarchy is traversed from the top until the authoritative DNS server for the queried hostname is located and responds with the IP address. However, to improve the performance of DNS, responses can be cached for some time in servers along the path. Most devices will not query the root zone themselves but will query a local DNS server that acts as a resolver, which might query another DNS resolver. For example, home routers typically act as a DNS resolver and the first hop in the DNS chain for all computers and devices on the local network. Routers also typically forward requests to DNS resolvers operated by the customer's ISP.
Understanding how DNS works is essential because any server in that chain can be a weak link and a point from where attackers can serve rogue responses. Some malware changes the DNS settings on computers to use DNS servers operated by attackers, in which case the users of the infected computers will be affected. Mass attacks have compromised the DNS settings on home routers, known as router pharming, affecting all users of the networks served by those routers. Other attacks compromise an ISP's DNS resolvers, in which case all of the ISP's customers who rely on those servers could be affected.
Enter DNSSEC
DNSSEC was designed to address those risks and provide cryptographic verification through digital signatures that can be used to validate that records delivered in a DNS response came from the authoritative DNS server serving the queried domain name and haven't been altered en route.
Like Transport Layer Security (TLS) and other secure communication protocols, DNSSEC relies on public key cryptography. Each authoritative name server has a vital pair of private and public keys that is cryptographically linked. The private key is used to sign record sets in a zone, and the signature is published as a DNS record. The public key can validate and store the signature in a DNS record.
How do resolvers ensure the signature and the public key came from the real authoritative name server and not a man-in-the-middle attacker? They go higher up in the hierarchy chain to the parent zone of the child zone whose signature they want to validate. For example, the .com zone is the parent of the google.com zone and the. (root) the zone is the parent of the .com zone.
Another private and public-private key pair that DNS servers use is the key-signing key (KSK). The private KSK key is used to sign the public key from the first pair used to sign records. The public part of the KSK is then given to the parent zone, which publishes it as part of its records for the child zone and is essentially used to authenticate that the information presented in the child zone is valid.
To summarize, a DNS resolver uses a name server's public key to check that the records it provides are signed with its corresponding private key. It then makes sure that the public key presented by the server in the first place is legitimate by looking at another record that contains a signature of that key and compares it with a record from the parent zone -- called a DS record -- to validate it. This establishes a chain of trust between parent and child zones.
If you go higher and higher in the chain, which validates the topmost key pair used to sign the Internet's root DNS zone? The root key pair is generated in a hardware security module kept in a secure location and is rotated periodically in a public and highly audited ceremony involving trusted community representatives worldwide. There is also a critical recovery process in the event of a significant catastrophe where several individuals known as Recovery Key Share Holders need to come together in the same place and use cryptographic tokens to reconstruct the key.
DNSSEC Deployment and Adoption
APNIC, the Internet registry administering IP addresses for the Asia-Pacific region, has a project monitoring DNSSEC validation worldwide. According to the latest statistics, the global rate of DNSSEC validation is around 26%, but validation rates vary significantly by country and region. The US has a DNSSEC validation rate of 30%, Canada only 17%, Western Europe 46%, Eastern Europe 26%, and Africa and Asia around 24%. In some countries, however, DNSSEC validation is over 90%.
When you look deeper into the data, you discover that in parts of Asia, for example, the dominant ISPs chose to just forward DNS queries to Google's Public DNS resolver instead of running their local DNS servers, Dan York, leader of the Internet Society's Open Standards Everywhere project, tells CSO. In other regions, large ISPs have decided to turn on DNSSEC validation on their DNS resolvers in recent years, for example, Comcast in the US, he says.
DNSSEC deployment has many layers. It started with the generation of the first root key pair in 2010, but then the key pair was updated in a rollover process that took several years to plan and execute and was finalized in October 2018. The public part of the key pair had to be shared with internet service providers, enterprise network administrators, DNS resolver operators, DNS resolver software developers, system integrators, and hardware and software distributors, which was a lengthy process. The TLDs and ccTLD operators also had to generate and deploy their keys and processes to enable DNSSEC for their respective DNS zones. Then there's the issue of individual domain owners choosing to sign their records.
"Deployment is moving on," York says. "I think there was a pause between 2015 and 2018 while we waited around for changing the root key, where people running the DNS infrastructure wanted to wait and see how the root key rollover would go. It was completed in 2018, and all things are good; the lights are green, and we're seeing how DNSSEC deployment is going up in the charts."
There are some challenges, especially in the enterprise space, according to York, when it comes to signing their domains and rotating keys. In cases where the domain registrar is also the DNS provider and maintains the authoritative servers for a domain, they can do the signing automatically and transmit the signature records to the TLD to establish the chain of trust, so the process is pretty seamless. However, enterprises tend to run their DNS servers or use content delivery networks or DNS providers that are not also registrars. They need to handle this process themselves.
"When you sign a domain, you must give this little record -- a DS record -- to the TLD registry -- .org, .com, .bank, etc. It's part of this chain of trust that verifies your domain is signed," York says. "The challenge with many enterprises is that they want to go and sign their records .., but then they have to make sure that when their signing key gets changed, it gets communicated to the TLD. Usually, they only have to do that once a year, but this is one part that some enterprises find a little clunky."
There have been incidents in the past where websites became unavailable because of DNSSEC misconfigurations or expired records -- the NASA and HBO Now websites are two examples. By comparison, the TLS/SSL industry and Certificate Authorities have managed to automate some processes involving certificate and key rotations. "It's something enterprises have to think about a bit," York says. "There's some work underway. Some standards allow people to do this. They just have to understand that these things exist."
Also contributing to DNSSEC deployment, according to York, is the increased adoption of DANE (DNS-based Authentication of Named Entities). This protocol relies on DNSSEC records to bind TLS certificates to domain names, telling clients exactly which TLS certificate they should accept for a particular server. This is meant to prevent TLS interception, where a proxy sitting between a user and server can terminate the TLS connection and serve it back to the user with a different certificate. It also makes it possible to use and trust certificates announced by a domain via DNS and cryptographically signed with DNSSEC, even if they haven't been issued by a publicly trusted Certificate Authority (CA).
"This hasn't taken off in the browser space, largely because extra checks are involved, and browsers are focused on performance and speed, but where it has come into play is with secure email," York says. "There's a growing number of people using DANE, signed by DNSSEC, to secure encrypted email from email server to email server. That's an interesting aspect, and it's something enterprises can look at: Is this a way to make their email more secure by providing these kinds of records for their email servers?" York thinks we won't see DNSSEC adoption explode as we did with TLS, especially HTTPS, after Google and other large tech companies put their power behind it and made it default and mandatory for different services and applications. It will likely be slower growth as more ISPs begin to understand the value of using it to check things, and it gets added and turned on in more and more tools, devices, and applications.
If you are an organization or an individual with an online presence for your organization, now it's time to use a distributed network of DNS services that protect your online presence. Follow the “Learn More” button below to learn about our Private DNS services.
© 2019 - 2022 iBlockchain Bank And Trust Technologies Co., All Rights Reserved