Introduction to DNSSEC Monitoring

Posted by on March 31, 2017

The Domain Name System (DNS) is a cornerstone of the Internet. It is a globally distributed database with a hierarchical structure that maps domain names to IP addresses. While DNS has recently been in the spotlight due to large scale DDoS attacks, its lesser known brother DNS Security Extensions (DNSSEC) has remained in the dark. In today’s blog post we discuss the origin of DNSSEC, how it works and why it is critical to monitor your DNSSEC implementation.


The Domain Name System is a framework of information distributed across hierarchical zones and built upon a query-response model. A client has to query for DNS information for the DNS servers to respond. However, there is no mechanism to authenticate the integrity of the data sent by the DNS server. Also, DNS messages are sent over a single, unencrypted UDP packet making it easy for hackers to intercept this data through man-in-the-middle attacks. DNS hijacks and cache poisoning are common manifestations of such attacks.

Birth of DNSSEC

DNS Security Extensions (DNSSEC) was introduced to counteract the shortcomings of DNS and prevent DNS security threats. Through public/private key encryption mechanisms, DNSSEC ensures:

  • Integrity of DNS data by making sure no one has tampered with the data.
  • Validate the zone authority through key delegation across zones.

If data privacy is what you are concerned about, then DNSSEC is not the right approach as data is not encrypted with DNSSEC.

Can DNSSEC Prevent DDoS Attacks?

If DNSSEC was built to overcome the security limitations of DNS, then can DNSSEC prevent DNS-based DDoS attacks? If that question popped up in your head, you are not alone. It is one of the frequently asked questions, especially given the recent eventful DNS-based DDoS attacks. To discourage a DDoS attack, DNSSEC would need to authenticate the identity of the client or DNS queries sent from the client. However, client authentication is not a part of DNSSEC. In hindsight, DNSSEC can sometimes aid a DDoS attacks as there are several new record types contributing to the attack traffic.

How DNSSEC Works

The whole point of DNSSEC is to provide a way for DNS records to be trusted by whomever receives them. And as DNS is a hierarchical framework, it means extending the trust across all zones, from the root server all the way down to the authoritative server. Building this trust across zones is commonly referred to as creating the “chain of trust”. DNSSEC is delivered using public/private key cryptography combined with new DNS records that facilitate building the chain of trust.

For the sake of this discussion, I’ll assume you are familiar with the basics of DNS, the concept of zones and the different record types. DNSSEC introduces a few new record types. Let’s focus only on three records types for today’s discussion.

  • RRSIG: Digital signature of DNS Resource Records (RR). Resource records provide information about DNS resources, such as their name and relation to other resources.
  • DNSKEY: Record that holds the public signing key
  • DS: Hash of a DNSKEY record

It’s easier to understand the principles of DNSSEC by walking through an example. Let’s assume you want to resolve the domain “” through DNSSEC by requesting for the A record. When a DNS resolver or client intends to use DNSSEC, the request is enabled by a flag in the query. This lets the authoritative name server know that it must respond with DNSSEC records, if available. Instead of going down the DNS tree from the root zone (.) to the ‘’ zone (Figure 1), let’s flip the discussion and take a bottom-up approach to understanding DNSSEC.

Figure 1
Figure 1: DNS Tree Hierarchy for the domain

Building the Trust Tree

Step 1: When the authoritative name server receives a DNSSEC enabled query for the A record of, it sends the A record along with a digital signature of the A record. It first hashes the A record and signs the hash with a private key, known as the Zone Signing Key (ZSK), creating a digital signature. The digital signature or RRSIGA record is then sent to the DNS resolver. The ZSK is specific to a zone, as it is used to sign any RR within a zone. In this example, the private ZSK is only relevant to the zone.

Step 2: Upon receiving the A record and the RRSIG record, the DNS resolver queries the authoritative name server for the public keys. Without the public key, the DNS resolver cannot validate the authenticity of the data in the A record. The authoritative name server sends the public ZSK in a DNSKEY record. The DNS resolver now has all the information needed to validate the A record. The DNS resolver decodes the RRSIGA with the public ZSK and compares the hash with its own hash generated from the A record. If it matches, it can trust the contents of the A record.

Step 3: The above step is only valid if one can completely trust the authenticity of the public ZSK key. DNSSEC tightens security by generating yet another key, the private Key Signing Key (KSK) to digitally protect the public ZSK key. The private KSK is used to digitally sign the public ZSK, creating yet another RRSIGpublic ZSK record. The RRSIGpublic ZSK record is sent to the DNS resolver along with the DNSKEY record of the ZSK. In order to validate the public ZSK, the DNS resolver still needs the public KSK key.

The authoritative name server sends the public KSK as a digital signature (RRSIGpublic KSK) of the DNSKEY record. The DNS resolver can now validate the ZSK key. At this stage, we can guarantee the integrity of the A record, ZSK key and finally validate the entire child zone.

Step 4: However, the validity of the zone is dependent on the validity of the public KSK key. DNSSEC leverages the hierarchical framework of DNS by passing the baton to its parent zone (org.) to validate the public KSK key. The child zone ( exchanges the hashed public KSK with the parent zone behind the scenes as a DNSKEYpublic KSK record. The DNS resolver queries for the DS record from the parent zone which holds the public KSK of the child zone. The parent server sends a DS record and a digitally signed RRSIG DS. The exchange of the keys between zones happens ahead of time, right when DNSSEC is enabled for the zones. At this point, the DNS resolver has successfully validated the child zone ( But the parent zone is still not authenticated!

As you rightly imagine, this process repeats itself until the root zone. As the root zone is the final zone and there is no higher authority, the public key required to validate the root is assumed to be right. ICAAN publishes the root zone key and is stored internally across all DNS resolvers. As the chain of trust runs through the entire DNS tree, it is critical to maintain and coordinate DNSSEC entries across all the zones. Figure 2 below represents each of the stages described above sequentially for the child zone (

Figure 2
Figure 2: DNSSEC validation chain across a single zone.

Monitoring and Validating DNSSEC

DNSSEC failure even in a single zone means complete failure of DNSSEC. If you have enabled DNSSEC for your domain, proactively monitor and verify the trust tree.

With ThousandEyes, you can validate the chain of trust from the root zone to the child zone by using the DNSSEC Trace test. Every iteration of the test walks through the steps described in the previous section and verifying the trust tree. The result of the test is a binary value (PASS or FAIL) and plotted against the standard ThousandEyes timeline you are familiar with (Figure 3).

Figure 3
Figure 3: Validate your DNSSEC implementation through DNSSEC Trace.

As the point of DNSSEC is to validate not just the authoritative server, but the entire hierarchy, a failure in any leg is attributed to the complete failure of DNSSEC (Figure 4).

Figure 4
Figure 4: Cloud agents fail DNSSEC validation due to lack of public keys.

With DNSSEC Trace, view the delegation of trust between child and parent zones along with the different key types exchanged for a single zone. If you have DNSSEC implemented for a domain, walk down the trust tree from child zone ( to the root zone (.) to check if the trust delegation is working as expected.

Figure 5
Figure 5: Walk down the Trust Tree to view chain of trust across zones.

The DS record of the child zone (delegated by the parent zone) is computed over multiple hash algorithms (indicated through digest type) to ensure backward compatibility at the DNS resolver. To verify the mapping of each DNSSEC record exchanged from the root zone to the child zone, use the Data Chain view, as shown in Figure 6.

Figure 6
Figure 6: Verify DNSSEC mapping from the Data Chain view.

Ready for DNSSEC?

DNSSEC is not a new protocol and has been around for nearly a decade. But the complexity of implementing, validating and troubleshooting DNSSEC has contributed to slow adoption rates. If you are bought into the idea of DNSSEC and plan to implement it, make sure that you are monitoring the DNSSEC trust chain. A broken chain in the DNSSEC tree provides no security at all, and all your efforts would be wasted if it was not verified. Interested in seeing how your DNSSEC implementation is performing? Sign up for a free trial and see for yourself.