A Guide to Using DNSSEC to Secure DNS

The Internet is a global network that connects everyone and everything. People share their profiles on social networks, businesses conduct e-commerce transactions, content producers put their creations online, and much more. This web of connectivity has fostered innovation, enabled widespread information sharing, and made doing business easier. Unfortunately, it has also provided an opportunity for malicious entities to exploit the weaknesses of different platforms to damage reputations or scam victims. 

The Domain Name System (DNS) is one of the key components of the global Internet, but it was designed decades ago, when the Internet was much smaller, was used mostly by professionals, and had few security concerns. Of course, the world is a much different place now, and due to how essential DNS is, it is constantly a threat target because attacks on it can disrupt nearly all Internet activity. From large-scale DDOS attacks to the hijacking of DNS servers to the poisoning of DNS records, bad actors are constantly a threat that administrators must be aware of.

The Internet Engineering Task Force (IETF), which is responsible for standardizing the DNS protocol, has been working steadily to improve the security and stability of DNS. One key enhancement is the DNS Security Extensions (DNSSEC) suite of features that adds authentication and validation in DNS using digital signatures. 

Summary of key concepts

Why DNSSEC?

DNS in the early Internet

Any communication request you make over the Internet—like sending a WhatsApp message, viewing a YouTube video, posting an Instagram story, or visiting a search engine to look for some answers—starts with a DNS resolution request. Your computer or smartphone initiates communication with the remote server, and the Domain Name System provides the IP address mapped with the remote system’s hostname. 

DNS was standardized in the early 1980s, when the Internet was in its early stages. There were relatively few systems and networks then, most were part of trusted organizations, and the primary concern was ease of communication rather than security. For this reason, DNS was made simple: Your computer would request an IP address from a DNS resolver and accept the answer unconditionally without verifying if the answer came from an authentic source or if the return information had been modified.

DNS spoofing and cache poisoning attacks 

As the Internet footprint has expanded over time and more and more systems have been connected, bad actors have constantly tried to find and exploit vulnerabilities in different systems and applications. The basic DNS system has multiple vulnerabilities, including spoofing and cache poisoning.

Spoofing is a mechanism where a legitimate answer to a DNS query is replaced by a forged one. Cache poisoning is when a bad actor corrupts the DNS cache of DNS resolvers, making them return the address of a malicious website. 

A man-in-the-middle (MITM) attacker can intercept DNS queries by spoofing the address of a legitimate authoritative DNS server. The attacker will change the DNS response to point to a rogue website. The result is that the cache in the DNS resolvers gets poisoned with incorrect information. Even some very big and famous organizations have been targeted.

Imagine a malicious entity that wants to steal your Facebook credentials or something even more serious, like your banking information. The attacker creates a replica of the website and poisons the cache of the DNS resolver. When you try to log in to Facebook or your bank’s website, the DNS resolver returns the forged IP address. Your browser connects with the malicious website without your knowledge, where you enter your credentials, which the attacker captures.

The need for DNS Security Extensions (DNSSEC)

The vulnerabilities described above made clear the need to improve DNS by including some authentication and verification mechanisms to ensure that malicious entities have not altered DNS query responses. Recognizing this requirement, the DNS Security Extensions (DNSSEC) suite was standardized in 2005, adding data origin authentication and data integrity protection to the Domain Name System.

How does DNSSEC work?

DNSSEC uses a public/private key cryptography mechanism to authenticate that data comes from an authentic zone and that the response is not modified in transit. 

DNS is a hierarchical system, starting with the root zone, going down to the top-level domain (TLD) and, finally, the authoritative DNS servers of specific domains. This hierarchy requires that a chain of trust be created. When a child zone provides a cryptographically signed response, the parent (TLD) must validate the signing of the child zone’s keys with its own keys. In turn, the keys of the TLD zone require validation, which the root zone performs. Since the root zone is at the top of the hierarchy, it becomes the trust anchor itself. 

Details of the DNS hierarchy with the chain of trust and DNSSEC validation are discussed in more detail in the following sections (including an example of zone traversal).

Resource records for DNSSEC

DNSSEC associates digital signatures with resource record sets (RRsets). RRsets group DNS records with the same name into a set. For example, the following three AAAA records for www.example.com will be bundled into a single RRset.

www.example.com	IN	AAAA		fd15:9203:bbb4:64b2::100
www.example.com	IN	AAAA		fd15:9203:5802:ea4a::100
www.example.com	IN	AAAA		fd15:9203:6854:64b2::100

The DNSSEC standard specifies the following record types for signing and signature validation.

• DNSKEY resource records are used to store the public keys. These keys are asymmetric: The public keys are stored in the DNS records and private keys are used for signing and are not published.
• RRSIG (resource record signature) stores digital signatures for DNS resource record sets. 
• NSEC/NSEC3 (next secure record) provides an authenticated mechanism to return a signed answer for a record that does not exist.
• DS (delegation signer) is the hash of the DNSKEY records stored in the parent zone.
• CDS/CDNSKEY (child DS / child DNSKEY) records are used for automated updates of DS and DNSKEY records with the parent zone.

Zone-signing keys, key-signing keys, and delegation signer

As discussed in the previous section, we need to establish a chain of trust. The root zone validates the TLDs, and the TLDs, in turn, validate the registered domains. Once a zone is signed, the key records are stored in the TLD to validate its signature. 

In cryptography, it is a best practice to rotate keys as often as practically possible. Following this guideline, we should rotate the domain signing keys, but with each key rotation, if we also have to update the validation records in the TLD, the process would become very cumbersome.

To ease this process, two types of keys are introduced: the Key-Signing Key (KSK) and Zone-Signing Key (ZSK). The KSK is used to sign the ZSK, which is used to sign the zone records. In the parent zone, a cryptographic hash function is used to store the fingerprint of the KSK, called the delegation signer record, instead of the actual key. This keeps the size of the records small in the parent zone. The authoritative DNS administrator can rotate the ZSK as required without updating the DS record in the parent TLD.

The DNSSEC validation process and the chain of trust

Let’s recap how DNS resolution works with DNSSEC validation, completing a chain of trust. Most DNS resolvers are configured with the public key of the root zone, which is called the trust anchor. With this trust anchor, the resolvers implicitly trust the records the root zone provides. The security of the root key is extremely critical as the chain of trust begins with this key; details of the root key signing process are published in the ICANN announcements.

Referring to the diagram below, let’s say a client initiates a query for the domain example.com using a DNSSEC-aware resolver (1). The resolver goes to the root DNS server (2), which provides the .com TLD servers and the .com TLD zone’s DS record (3). When a DS record is returned, the resolver knows that the .com zone is DNSSEC-secured. 

The resolver next queries the TLD servers (4), which provide the authoritative name servers for example.com along with the DS record (5). The resolver hashes the KSK of the TLD zone and compares it with the DS record received from the root zone (6). If the hash matches the DS record, the resolver knows that the records provided by the TLD zone can be trusted. 

The resolver now sends a query to the authoritative name servers (7), receiving the records and DNSKEY (8). The resolver hashes the KSK provided by the authoritative name servers, and if the hash matches the DS record provided by the TLD (9), the zone records of example.com are considered trusted. The DNS resolver then returns the validated records back to the client (10).

How to configure DNSSEC validation

DNSSEC deployment across the globe is not automatic; it currently requires manual steps to enable DNSSEC validation. Internet service providers or business enterprises that deploy and manage their own DNS resolvers must enable DNSSEC validation in their recursive DNS servers. 

As a domain owner, you should select a domain registrar that supports DNSSEC. The registrar must be able to sign and update DS records and provide DS records to the parent TLD. In a case where you would like to disable DNSSEC for your domain or to migrate to a non-DNSSEC capable registrar, you must first delete your DS records from the parent TLD and wait for cached records to expire (based on their TTL values) before proceeding further.

For hosting, you can choose a DNS hosting provider that supports DNSSEC. Alternatively, you can deploy your own DNS infrastructure and enable DNSSEC signing in your authoritative DNS servers (discussed below).

DNSSEC-aware recursive DNS servers perform validation of each query from the remote servers using the chain of trust discussed above. The resolver verifies that the answers are legitimate using public key cryptography. 

For many years now, almost all DNS resolvers have supported DNSSEC validation. Turning this validation on is generally a simple step involving a few configuration lines. After validation is turned on, the resolver will start protecting its end users from receiving data that has been tampered with, returning a SERVFAIL status when the validation check fails. A caveat is that this protection holds true only for those domains that are secured via DNSSEC.

BIND DNS recursive server configuration

To enable DNSSEC validation in an ISC BIND resolver, edit the options configuration file (/etc/bind/named.options) and ensure that the following line is configured. In recent releases of BIND, this option is enabled by default; this must be done explicitly in older BIND versions (up to 9.11).

options {
	. . . .
	. . . .
	dnssec-validation auto;
	. . . .
	. . . .
};

PowerDNS Authoritative Server Configuration

Configuring and generating the DNSSEC keys and signing the zone records can be complicated. PowerDNS authoritative DNS contains support to ease the administrative overhead and enable the zone’s signing with a simple command-line interface, though using a secrets management tool is recommended. As a prerequisite, you must enable DNSSEC processing on the backend configured with PowerDNS. For example, configure the following options in the main PowerDNS configuration file (/etc/powerdns/pdns.conf) if you use the SQLite backend.

. . . .
. . . .
# Enable Sqlite3 backend
launch=gsqlite3
# Path to Sqlite3 DB file
gsqlite3-database=/var/lib/powerdns/pdns.sqlite3
# Enable DNSSEC processing
gsqlite3-dnssec
. . . .
. . . .

To secure a zone with DNSSEC, use the following command line.

$ sudo pdnsutil secure-zone example.com

By default, PowerDNS uses NSEC to return answers for NXDOMAIN queries. To convert this to NSEC3, use the following command line.

$ sudo pdnsutil set-nsec3 example.com '1 0 0 -'

Ensure that the secondary DNS servers are updated with the new or updated keys; increment the SOA serial number.

$ sudo pdnsutil increase-serial example.com

Configure DS records with the domain registrar

After enabling DNSSEC for the zone, you need to update the parent or TLD with the DS record for the zone. The following command will show the hash, algorithm, and digest type used for generating the hash.

$ sudo pdnsutil show-zone example.com
. . .
Zone has hashed NSEC3 semantics, configuration: 1 0 0 -
keys: 
ID = 2 (CSK), flags = 257, tag = 30717, algo = 13, bits = 256	  Active	 Published  ( ECDSAP256SHA256 ) 
. . .
DS = example.com. IN DS 30717 13 2 13dd5 .......... 61f91bda8 ; ( SHA256 digest )

You must securely provide the following information from the output above to your domain registrar.

Domain:   	example.com
Algorithm:	ECDSA
Digest Type:	SHA256
Digest:		13dd5 .......... 61f91bda8
keyTag:		30717

Now your domain example.com is secured via DNSSEC, and the resolvers can verify the identity of the provided information via the chain of trust. 

DNSSEC verification

Correct implementation of DNSSEC for a zone ensures that end-users get verified answers. An incorrect implementation of DNSSEC can inhibit end-users from getting the domain records, which results in your domain being invisible on the Internet. 

Online verification tools

The Internet Society publishes a list of tools for testing and implementing DNSSEC. Verisign has provided an online DNSSEC analyzer to test the chain of trust for a provided domain. The tool performs DNSSEC validation checks from the root to the authoritative DNS for the zone and will highlight any issues found during testing.

Source: https://dnssec-debugger.verisignlabs.com/verisign.com

Another online tool is DNSViz, which visually analyzes the DNSSEC verification and DNS resolution from the root down to the zone.

Command line verification

You can also test the DNSSEC status of domains using the dig command line utility, which you can download from the ISC website if you don’t have it installed. You can check the DNSSEC records and status by making a query to a DNSSEC-aware resolver, adding the +dnssec option, and displaying the keys on multiple lines (+multiline) for visibility.

$ dig verisign.com @1.1.1.1 +dnssec +multiline

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> verisign.com @1.1.1.1 +dnssec +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63981
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;verisign.com.		IN A

;; ANSWER SECTION:
verisign.com.		60 IN A	69.58.187.40
verisign.com.		60 IN A	72.13.63.40
verisign.com.		60 IN RRSIG A 8 2 60 (
				202309192318 202308202318 17355 verisign.com.
				ob16wft/jzpDZeZbeAJMBF1hX7jhtfwqj4G1RQkJkKVN

In the output above, the ad flag shows that the domain has passed all the DNSSEC validation processes. A successor to the dig utility is Delv. The tool works like dig but has a better understanding of DNSSEC implementation as it uses the same code as the BIND DNS server for validating the DNSSEC chain. The tool will specifically return a “fully validated” report for a successful DNSSEC implementation.

$ delv verisign.com @1.1.1.1 +multi +rtrace
;; fetch: verisign.com/A
;; fetch: verisign.com/DNSKEY
;; fetch: verisign.com/DS
;; fetch: com/DNSKEY
;; fetch: com/DS
;; fetch: ./DNSKEY
; fully validated
verisign.com.		60 IN A	72.13.63.40
verisign.com.		60 IN A	209.131.162.45
verisign.com.		60 IN RRSIG A 8 2 60 (
				202312022319 202311022319 41998 verisign.com.
				AFBYZG/6VHvIYNdZaKBWzKnGEpgqICF9onlqjOLPmT8T

You can get more details for testing your DNSSEC implementation via the BIND documentation.

Global DNSSEC implementation

Proper DNSSEC implementation across the globe for all domains is important to ensure a safer Internet. Current DNSSEC adoption is slow, however, for multiple reasons: 

• Technical staff require proper training.
• Mistakes in DNSSEC implementation can make domains disappear from the Internet.
• Domain registries and registrars require hardware and software upgrades due to zone sizes becoming much bigger after storing DNSSEC records and DNS responses also growing in size. 
• An individual organization won’t see the full benefits of DNSSEC unless everyone else also implements it.

TLDs and DNS zone statistics

All the generic top-level domains (gTLDs) and most country-code TLDs (ccTLDs) have deployed DNSSEC. The Internet Society tracks the progress of DNSSEC implementation across the TLDs and provides graphs and statistics.

Source: https://www.internetsociety.org/deploy360/dnssec/maps/

Verisign keeps a scoreboard of .com and .net domains secured via DNSSEC. The current stats are that more than 5% of .com and around 4.5% of .net domains with DS records are published in the TLDs.

Global resolver statistics

The Asia Pacific Network Information Center (APNIC) tracks DNS traffic from resolvers and publishes the rate of DNSSEC validation across the globe. It provides statistics for each region, country, and network performing DNSSEC validation. Currently, over 30% of DNS resolvers are performing DNSSEC validation worldwide.

The figure below shows the DNSSEC validation percentage by country. More green means a higher percentage of DNSSEC traffic; more red means a lower percentage.

Challenges related to DNSSEC

DNS zone traversal using NSEC

When you query a record that does not exist, the DNS server returns an empty record with an NXDOMAIN status. With an empty answer, it is not possible to verify its authenticity. DNSSEC solves this with a next secure record (NSEC). A signed zone with NSEC will return the next valid record according to the DNSSEC sorting criteria. 

This solves the problem of returning a signed answer even in the case of an empty record. Still, it introduces another vulnerability: It allows a bad actor to expose all the DNS records in a zone by walking through all the NSEC records. This problem is solved using NSEC3, which creates a hash of all the valid records. This obscures the answers to the queries for nonexistent records.

DNS reflection/amplification attacks

DNS generally uses UDP for queries because it is a simpler and quicker protocol than TCP. However, the downside of UDP is that it is stateless, and it is very easy to spoof the IP address of a potential victim when using UDP for communication. This vulnerability is exploited to generate DDOS attacks using DNS reflection/amplification techniques. The typical size of a DNS response is 50-60 bytes. 

With DNSSEC-signed zones, the response size can increase up to 512 bytes or more, and the impact of DDOS attacks using such zones becomes much more amplified.

DNS Response Delays

Another challenge with DNSSEC implementation is that it significantly increases the DNS resolution time. The DNSSEC validation process requires additional steps to validate the chain of trust. In the current fast-paced world where every millisecond matters, this becomes one of the reasons for some organizations not implementing DNSSEC for their domains. This APNIC blog article covers this challenge in more detail.

Summary of key concepts

DNS is one of the most critical components of the global Internet and is frequently targeted by malicious entities. DNSSEC ensures a safer Internet by adding a verification mechanism missing in the initial DNS standards. 

DNSSEC requires establishing a chain of trust from root servers to TLD servers to authoritative servers. It also requires that the DNS resolvers enable DNSSEC verification. Resolvers can verify that the DNS response comes from an authentic source and has not been modified while in transit. 

DNSSEC adoption is picking up slowly owing to its complexity and for other reasons. However, a successful implementation of DNSSEC can be ensured with proper knowledge of the technology and the use of appropriate tools.

FAQs