Preparing for DNSSEC: Best Practices, Recommendations, and Tips for Successful Implementation

Contents

Overview
Understanding DNS
      What is DNS
      DNS Terminology
      Primary Function of DNS
Understanding DNSSEC
      Difference Between DNS and DNSSEC
      Potential Networking Challenges with DNSSEC Deployment
Preparing Your Network 
      Connectivity Over UDP and TCP port 53
      IP Fragmentation and TCP Segmentation
      Inspection of Large DNS Packets
      Network Address Translation
Preparing Your DNS Infrastructure 
      Updating DNS Servers
Troubleshooting DNSSEC 
Conclusion 
Acknowledgments
Additional Resources
References



Overview

This white paper provides a general understanding of Domain Name System Security Extensions (DNSSEC) and offers best practices and advice for implementing DNSSEC in a network infrastructure. The paper is divided into the following sections:

  • Understanding DNS
  • Understanding DNSSEC
  • Preparing Your Network
  • Preparing Your DNS Infrastructure
  • Troubleshooting DNSSEC
  • References and Resources

Understanding the Domain Name System


What is the Domain Name System?

The Domain Name System (DNS) is a globally distributed, scalable, hierarchical, and dynamic database that provides a mapping for hostnames, IP addresses (both IPv4 and IPv6), text records, mail exchange information (MX records), name server information (NS records), and security key information defined in Resource Records (RRs). The information defined in RRs is grouped into zones and maintained locally on a DNS server to be retrieved globally through the distributed DNS architecture.

DNS can use either the User Datagram Protocol (UDP) or Transmission Control Protocol (TCP); historically, it uses a destination port of 53. When the DNS protocol uses UDP as the transport, it has the ability to deal with UDP retransmission and sequencing.

DNS is composed of a hierarchical domain name space that contains a tree-like data structure of linked domain names (nodes). Domain name space uses Resource Records (RRs) that store information about the domain. The tree-like data structure for the domain name space starts at the root zone "." that is the top-most level of the DNS hierarchy. Although it is not typically displayed in user applications, the DNS root is represented as a trailing dot in a fully qualified domain name (FQDN). For example, the right-most dot in "www.cisco.com." represents the root zone. From the root zone, the DNS hierarchy (tree) is then split into sub-domain zones (branches).

Each domain name is composed of one or more labels. Labels are separated with a "." character and may contain a maximum of 63 characters. A FQDN may contain a maximum of 255 characters, including the "." character. Labels are constructed from right to left, where the label at the far right is the top-level domain (TLD) for the domain name. The following example shows how to identify the TLD for a domain name:

"com" is the TLD for www.cisco.com because it is the label that is farthest to the right

DNS Terminology

To understand the DNS and the DNS-specific recommendations in this document, operators and administrators should be familiar with the following terms:

  • Resolver: A DNS client that sends DNS messages to obtain information about the requested domain name space.
  • Recursion: The action taken when a DNS server is asked to query on behalf of a DNS resolver.
  • Authoritative Server: A DNS server that responds to query messages with information stored in Resource Records (RR) for a domain name space stored on the server.
  • Recursive Resolver: A DNS server that recursively queries for the information requested in the DNS query.
  • FQDN: A Fully Qualified Domain Name is the absolute name of a device in the distributed DNS database.
  • Resource Record: A Resource Record (RR) is a format used in DNS messages that is composed of the following fields: NAME, TYPE, CLASS, TTL, RDLENGTH, and RDATA.
  • Domain: A domain name and all domain names below it, sub-domains; that is, all domain names ending with the domain name. Domains are delegated from one nameserver to another.
  • Zone: A database that contains information about the domain name space stored on an authoritative server. A zone is the same as a domain minus all delegated domains.
  • Resource Record Set: All resource records with the same NAME, TYPE, and CLASS; however, the RDATA is different. A response from DNS is always a complete Resource Record Set (or RRSet in short). An example of an RRSet would be multiple NS records for a respective zone or domain.
  • Delegation Signer (DS): The DS RR is a DNSSEC record type that is used to secure a delegation for a zone.
  • Zone Signing Key (ZSK): This is used to sign all the RRSets in a zone.
  • Key Signing Key (KSK): This is used to only sign the DNSKEY RRSet.
  • DNSKEY Resource Record: This DNSSEC RR is used to store the public keys that are used to sign the records for a zone. This RR can contain either a ZSK or a KSK.
  • EDNS: Extension Mechanisms for DNS (EDNS, as defined in RFC 2671) is an IETF specification written to remove DNS message size restrictions initially imposed (RFC 1035 Section 2.3.4. Size limits) on the DNS protocol.  EDNS allows clients to advertise their capabilities to DNS servers and one of those capabilities that is related to DNSSEC is the ability for a client to advertise its reassembly buffer to a DNS server, for example, a DNS client can reassemble a DNS message sent over UDP that is larger (2000 bytes) than the legacy limit of 512 bytes.
  • DNSSEC OK (DO) EDNS header bit: This is a bit in the EDNS header that, when set to one ("1") in a DNSSEC-enabled query messages, indicates to the server that the resolver is requesting and able to accept DNSSEC RRs in the query response message.

Primary Function of DNS

DNS translates hostnames to IP addresses or IP addresses to hostnames. This translation process is accomplished by a DNS resolver (this could be a client application such as a web browser or an e-mail client, or a DNS application such as BIND) sending a DNS query to a DNS server and requesting the information defined in a RR. Some examples of the DNS resolution process follow:

  • If the DNS server is configured only as an authoritative server and it receives a DNS query message asking about information of which the server is authoritative, the DNS server will check locally stored RR information and return the value of the record in the Answer Section of a DNS response message. If the requested information for the DNS query message does not exist, the DNS server will respond with a NXDOMAIN (Non-Existent Domain) DNS response message or a DNS Referral Response message.
  • If the DNS server is authoritative, not configured as a recursive resolver, and it receives a DNS query message asking about information of which the server is not authoritative, it will cause the server to issue a DNS response message containing RRs in the Authority Section. The address mapping for the FQDN from that section may be present in the Additional Section. This informs the DNS resolver where to send queries in order to obtain authoritative information for the question in the DNS query.  This condition occurs due to DNS zone delegation.   The DNS response message described above is also known as a DNS Referral Response message.
  • If the DNS server is not authoritative but is configured as a recursive resolver and it receives a DNS query asking about information (assuming the query requests recursion, that is, if the RD flag is set), it the query request will cause the server to recursively query (iterative queries) the DNS architecture for the authoritative DNS server of the information included in the DNS request. Once the recursive DNS resolver has obtained this information, it will provide that information to the original DNS resolver using a DNS response message and the RR will be non-authoritative (since the recursive DNS resolver is not authoritative for the requested information). The recursive DNS resolver may also have knowledge about the requested information stored in DNS cache. If the requested information is present in the DNS cache, then the recursive DNS resolver will respond with that RR information.

A summary of the three examples follows:

  • A DNS query arrives at the server
  • If the server has the DNS data either as authoritative or cached, the server will respond with the data
  • If the server does not have the DNS data, one of the following actions will take place:
    • If the server is configured to allow DNS recursion, and the query has the RD flag set, the server will itself query other DNS servers, fill its cache, and then respond as described above.
    • If the server is not configured to allow DNS recursion, or the query does not have the RD flag set, the server will respond with a DNS referral, that is, information about DNS servers that might have a better answer in the authoritative section.
    • A DNS server might respond with "no such data exists" if data does not exist for the DNS query in question.
    • A DNS server might respond with an error code, for example if the server is misconfigured.

Additional information is available in DNS Best Practices, Network Protections, and Attack Identification.

Understanding DNSSEC

DNSSEC supplements the hierarchical nature of the DNS with cryptographic characteristics that make it possible to verify the authenticity of information stored in the DNS. This validation makes it possible for resolvers to be assured that when they request a particular piece of information from the DNS, that they do in fact receive the correct information as published by the authoritative source.

This assurance is made possible using cryptographic signatures included in the DNS by a source organization. These signatures are calculated on a complete Resource Record set, not individual Resource Records. The signatures are published in a DNSSEC-specific resource record type called RRSIG. For example, setting aside the requisite infrastructure, by publishing the signature for an A record, the source organization makes it possible for resolvers on the Internet to verify that the A record contains authentic data and is correct as published. A DNS server is only signing data for which it is authoritative, for example, the DNS server does not sign NS records that delegate subdomains from its zone.

A client computer with an embedded stub resolver sets the DNSSEC OK (DO) bit to 1 in outbound queries when it wants to use DNSSEC to verify the authenticity of DNS information. When a DNSSEC enabled DNS server receives a query with DO=1, it uses locally stored or received RRSIG records to cryptographically verify the authenticity of the DNS information. The verification result is communicated to the stub resolver using the Authenticated Data (AD) bit in the DNS response; where AD=1 indicates the DNS data is authentic, and AD=0 indicates that DNSSEC verification failed.

Difference between DNS and DNSSEC

From a network perspective, DNS and DNSSEC are very similar. DNSSEC requires an expanded set of DNS capabilities, and while DNS may have worked without them, DNSSEC will not.

For example, DNSSEC message sizes will be larger than DNS messages without DNSSEC, and that is managed with the help of the EDNS. This is simply the result of additional information being contained within the DNS responses. Without DNSSEC, DNS packets are typically less than 512 bytes in length. With DNSSEC, many DNS packets will exceed 512 bytes and may approach 4096 bytes. Additionally, end-to-end EDNS must be supported to carry the DO, AD, and other DNSSEC-specific header flags.
Because of the increased packet size, DNS with DNSSEC may use TCP more often then DNS without DNSSEC.

Potential Networking Challenges with DNSSEC Deployment

The networking-specific challenges from DNSSEC are largely the result of the differences mentioned previously: increased packet sizes, EDNS requirements and the more frequent use of TCP. Many firewall devices incorrectly limit DNS responses to 512 and prohibit DNS over TCP. These challenges and potential remedies are described in the next section of this document.

Preparing Your Network

This section summarizes some of the issues that may be encountered when DNSSEC packets are sent through network devices and how these issues can be addressed prior to DNSSEC traffic traversing the network. These solutions include the following:

  • Connectivity over UDP and TCP port 53
  • IP fragmentation and TCP segmentation
  • Inspection of large DNS packets
  • Network Address Translation

Connectivity Over UDP and TCP port 53

Because most DNS traffic  is sent over UDP port 53, any filtering of traffic that exists on the network is unlikely to impact future native DNS traffic that is traversing UDP port 53. However, if DNS traffic is not currently permitted to traverse TCP port 53, which is typically used for large DNS packets (that is, those greater than 512 bytes), any issues with DNS traffic over TCP port 53 will be exacerbated when DNSSEC packets begin arriving on the network, because many DNSSEC packets will be greater than 512 bytes due to the additional packet overhead of DNSSEC. If traffic using TCP port 53 is currently not permitted, or is being filtered to or from specific hosts or networks, then it may be necessary to account for new hosts and networks that could be sending DNSSEC traffic over TCP port 53.

In the following Cisco IOS Software Access Control List (ACL) example, 192.168.60.0/24 is the IP address space that is used by trusted DNS servers and 192.0.2.0/24 is the IP address space used by internal hosts sending DNS queries.

Figure 1. Cisco IOS Software ACL example

!
ip access-list extended dnssec
 ! !-- Allow for DNS packets over TCP port 53 !
 permit tcp 192.0.2.0 0.0.0.255 192.168.60.0 0.0.0.255 eq domain
 ! !-- Allow for DNS packets over the standard UDP port 53 !
 permit udp 192.0.2.0 0.0.0.255 192.168.60.0 0.0.0.255 eq domain
 ! !-- Deny all other DNS packets !
 deny   tcp 192.0.2.0 0.0.0.255 any eq domain
 deny   udp 192.0.0.0 0.0.0.255 any eq domain
 !
 permit ip any any
!

IP Fragmentation and TCP Segmentation

The presence of larger IP packets, such as those found when using DNS (mainly due to zone transfers, EDNS, and DNSSEC), translates to an increase in the probability that a large packet containing DNS information will exceed the Maximum Transmission Unit (MTU) at some point in transit. In cases where the packet exceeds the configured MTU of a Layer 3 interface, the packet will require fragmentation. However, in certain cases, the packet configuration (for example, if the Don't Fragment (DF) bit is set (= 1)), or the network configuration (for example,  ICMP messages indicating packets need to be fragmented are not received by the originating host) may not allow transmission of a fragmented packet. For this reason, it is necessary to account for the permitted MTU sizes through the use of features such as Path MTU Discovery (PMTUD) to ensure that large DNS packets are not discarded or subsequently dropped when they exceed the MTU size configured on a Layer 3 interface.

Similar to the large packets that are impacted by IP fragmentation issues, large DNS packets that use the TCP protocol (that is  53/tcp) may encounter issues due to TCP segmentation, which must be accounted for to ensure that large TCP-based packets are not discarded. For more information on TCP segmentation, reference Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC.

For more information about Access Control Lists and IP Fragments, refer to Access Control Lists and IP Fragments.

Inspection of Large DNS packets through Firewalls or Application Layer Gateways

Devices that perform Application Layer Inspection (ALI) may reject large (greater than 512 bytes) DNS packets.  Cisco ASA and PIX firewall products running pre-8.3 code versions that are configured with the default DNS inspection policy will only permit DNS packets up to 512 bytes. This message-length limit may not be large enough for an organization's internal clients, or for servers advertising that they want to receive and validate DNSSEC resource records. Based on internal testing performed by Cisco Security Research & Operations (SRO), we recommend using a message length size of 4096 bytes. No legitimate DNSSEC packets should be larger than 4096 bytes.

Cisco Adaptive Security Appliance (ASA) Software Version 8.2.2

A Cisco ASA running software version 8.2.2 or later may use the configuration shown in Figure 2 to alleviate the issues brought about by packets that are larger than the default maximum of 512 bytes.

Figure 2. Cisco ASA Software Version 8.2.2 Configuration

!
policy-map type inspect dns preset_dns_map
    parameters
        message-length maximum client auto
        message-length maximum 512
!

This configuration enables the ASA to behave according to DNSSEC RFC specifications. Using the message-length maximum client auto line allows the ASA to look into the DNS query packets and set the query response size according to the advertised EDNS buffer size. For more details, see the "Verifying infrastructure devices are DNSSEC aware/capable" section under Preparing your DNS Infrastructure.

NOTE: The command -message-length maximum client auto- was added to version 7.2.1 through the introduction of AIC inspection for DNS. However, if multiple maximum lengths were specified (as displayed in Figure 3), then the lesser of the two (typically 512 in the DNSSEC case) would be selected.

Cisco PIX Firewall or Cisco ASA Software Version 7.x

Customers running Cisco PIX Firewall or Cisco ASA Software Version 7.x may use the command shown in Figure 3 to modify the message length to 4096 bytes:

Figure 3. Cisco PIX Firewall or Cisco ASA Software Version 7.x Configuration

!
policy-map type inspect dns preset_dns_map
    parameters
        message-length maximum 4096
!

Cisco PIX Firewall Software Version 6.x

Customers running Cisco PIX Firewall Software Versions 6.x can use the command shown n Figure 4 to modify the message length to 4096 bytes:

Figure 4. Cisco PIX Firewall Software Version 6.x Configuration

!
fixup protocol dns maximum-length 4096
!

Network Address Translation

All DNSSEC configurations that make use of Network Address Translation (NAT) have been tested (Static 1-to-1 NAT, PAT, Identity NAT, etc.) and operated successfully (with the exception of NAT and packets requiring TCP segmentation, which were tested and had issues that are described in the next paragraph).

Customers with NAT configured on a Cisco IOS device may experience issues receiving large DNS query response messages when TCP is used as the transport. Cisco IOS NAT does not have support for reassembling TCP segments. The lack of support for TCP segment reaasembly is a well-known issue that is documented under the question "Q. What is the difference between IP fragmentation and TCP segmentation?" at the following link: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_q_and_a_item09186a00800e523b.shtml.  

Preparing Your DNS Infrastructure

The DNS infrastructure for most organizations is vast and often interpreted as complicated due to a general lack of DNS understanding.  It is critical to understand your infrastructure as you prepare for DNSSEC. DNS infrastructures are often running without any intervention, and with little knowledge, by most of the network users. The advent of DNSSEC has forced many organizations to learn, understand, and assess their DNS infrastructure to build a scalable infrastructure that suits the particular environment.  Because most organizations manage and maintain their own DNS servers and infrastructure equipment for their domains, DNS on a global scale is and will continue to be a distributed database. As an administrator or engineer, there are two options for organizations that want to register a domain name.  

  • Host your own DNS servers
  • Employ a hosting company to host your DNS servers

Note: These options are for a second-level domain name, for example, www.cisco.com, where .com is the Top Level Domain (TLD).

These two options are critical to understanding the perspective of preparing a DNS infrastructure. This document assumes that an organization is hosting its own DNS servers.

Preparing a DNS infrastructure for DNSSEC requires forethought and execution of the following essential components:

Ensure DNS Resolvers are DNSSEC Capable

Verify that the existing DNS infrastructure can support increased memory and storage requirements, as DNSSEC incorporates new RRs, namely DNSKEY (the DNS public key used to verify signatures), RRSIG (the resource record signature used to store the digital signatures), DS (the delegation signer that stores a hash of the public DNSKEY), and NSEC (the next security record pointer, which is also used to provide proof of non-existence of a RR). The addition of these RRs increases the size of zone files. The increased size requires DNS resolvers and other equipment to ensure the computing capacity to process and store the DNSSEC files and data. Moreover, it is recommended to take advantage of DNS resolvers that are configured to validate the signed responses.

DNSSEC provides signed responses that can be up to seven times the size of traditional DNS responses, which were typically limited to a maximum of 512 bytes. Note these larger and increased maximum payload DNS responses are often referred to as EDNS (extension mechanisms for DNS - RFC 2671).

Note: All versions of BIND 9 by ISC, Inc., and Name Server Daemon (NSD) by NLnet Labs are DNSSEC capable.

Verify Infrastructure Devices are DNSSEC-Aware and Capable

DNSSEC awareness and capability of infrastructure devices require that network and infrastructure devices do not drop or filter EDNS packets. Because most DNS-aware network devices limit DNS responses and queries to UDP packets that are no larger than 512 bytes (with the exception of zone transfers, which are larger and leverage the TCP protocol), it is critical to ensure that these devices can be configured to allow larger size packets (similar to the Cisco ASA and PIX platforms), or at the very least, can ignore the packet size.

Note: Ignoring the DNS packet size is not recommended; however, it may be the only option to allow the DNSSEC traffic to pass.

The Cisco ASA and Cisco PIX platforms handle traditional DNS traffic in the default DNS inspection engine that is enabled by default in the default inspection policy named “class inspection_default”.

The Cisco ASA and Cisco PIX DNS inspection:

  • Translates the DNS record based on the configuration completed using the alias, static, and nat commands (DNS Rewrite). Translation applies only to the A-record in the DNS reply; therefore, DNS Rewrite does not affect reverse lookups, which request the PTR record.
  • Enforces the maximum DNS message length (the default is 512 bytes and the maximum length is 65535 bytes). The Cisco ASA performs reassembly as needed to verify that the packet length is less than the maximum length configured and drops any packet that exceeds the maximum length.
  • Enforces a domain name length of 255 bytes and a label length of 63 bytes.
  • Verifies the integrity of the domain name referred to by the pointer if compression pointers are encountered in the DNS message.
  • Checks to see if a compression pointer loop exists.

For more details regarding DNS inspection, consult the Cisco ASA 5500 Series Configuration Guide.

The ASA/PIX platforms are DNSSEC-aware in that they understand what an EDNS packet is and how to properly interpret the DNS query/response message length provided in the EDNS packet, specifically the OPT record. By default, the Cisco ASA and Cisco PIX platforms make use of the factory pre-set configuration, which specifies a default DNS message-length maximum of 512 bytes as shown in Figure 5.

Figure 5. Cisco ASA and Cisco PIX Factory Pre-set Configuration

!
policy-map type inspect dns preset_dns_map
    parameters
        message-length maximum 512
!
policy-map global_policy
    class inspection_default
        inspect dns preset_dns_map
!
service-policy global_policy global
!

The default message-length limits the DNS response size to 512 bytes. In this default state, DNSSEC packets may be denied because the response size is too large.

Beginning with Cisco ASA/PIX Software Release 7.2, Cisco introduced the ability to identify EDNS packets, and set the DNS message length size according to the OPT record by making use of the message-length maximum client auto DNS configuration command.

When this command is enabled, the firewall will reference the EDNS packet (specifically, the OPT record) to properly set the message-length size. Non-DNSSEC (EDNS) DNS traffic will reference the “message-length maximum <512>” command to filter DNS packet size accordingly.

Alternatively, DNSSEC traffic can be passed through the firewalls by disabling the DNS inspection engine with the command shown in Figure 6.

Figure 6. Disabling the DNS Inspection Engine

!
no inspect dns
!

Note: Disabling the DNS inspection engine is not a recommended practice, but it will ensure the firewall does not participate or filter any DNS type traffic. Instead, DNS traffic will be forwarded without the firewall looking into the DNS details of the packet, including message-length.

Figure 7 shows a recommended configuration for both DNS and DNSSEC.

Figure 7. Configuring DNS or DNSSEC

!
policy-map type inspect dns preset_dns_map
    parameters
        message-length maximum client auto
        message-length maximum 512
!
policy-map global_policy
     class inspection_default
         inspect dns preset_dns_map
!
service-policy global_policy global
!

The configuration shown in Figure 8 will apply inspection to any DNSSEC packets according to the message-length maximum client auto configuration command that, as previously stated, will set the length of the DNSSEC message-length according to the size advertised in the EDNS packet. All non-DNSSEC DNS packets will continue to honor the packet size set by the message-length maximum <512> command, depending on the size specified.

Verify Bandwidth Allocations are Adequate to Support DNSSEC

As with the requirements to support the computing capabilities of DNSSEC, an organization's infrastructure (including routers, switches, gateways, VPN solutions, and more) requires the bandwidth capability to support the increased load of DNS traffic (EDNS) along with  more requests and larger responses. Environments that process high-volume DNS traffic must prepare and engineer reliable throughput solutions for the infrastructure equipment. Preparations can range from standard Layer 2 and Layer 3 solutions such as gigabit plus speed links to the consideration of such things as convergence times for routing protocols, timely failover solutions for redundancy options, and increased bandwidth needs.

Ensure the Organization is Making Use of DNSSEC-Aware or Supporting Registrars

Understand the capabilities of your DNS registrar(s). Verify that your registrar is DNSSEC-capable. The minimum DNSSEC support capabilities of a registrar must be that you can upload, replace, and remove published DNSKEY record (or DS) information for the keys that are used to sign the data in your zone.

A Domain Name Registrar is an organization or commercial entity accredited by the Internet Corporation for Assigned Names and Numbers (ICANN) or by a national country code top-level domain (ccTLD) authority to manage the reservation of Internet domain names in accordance with the guidelines of the designated domain name registries and offer such services to the public.


Understand and Effectively Execute Key Management Strategy and Process

Operational practices surrounding DNSSEC require maintaining the chain of trust (which can become quite lengthy) that DNSSEC is predicated on. The simple fact that DNSSEC makes use of asymmetric keys and signatures indicates a need for private and public key and signature management processes and strategies. Furthermore, it is imperative to understand that the responsibility for maintaining the chain of trust rests with many entities, including administrators and architects of secured zones, the signing authorities, and registrars.

Updating DNS Servers

A key element of a successful DNSSEC migration is the DNS server itself. Most DNS servers contain support for DNSSEC. BIND, which continues to be one of the most adopted DNS servers today, can be deployed for DNSSEC using various versions, most commonly version 9. On the Windows Server front, any Windows 2003 server needs to be upgraded to Windows 2008 for full DNSSEC compliance. Consult http://www.circleid.com/posts/dnssec_will_microsoft_have_enough_time/ prior to deploying DNSSEC in a Windows server environment.

Recursive resolvers must be DNSSEC-capable and configured to perform DNSSEC validation (that is, recognize the various DNSSEC messages, signatures, and keys). Examples of validating resolver are Bind version 9 or later and Unbound from NLNet Labs.

Troubleshooting DNSSEC

Before reviewing the common troubleshooting issues covered in this section, we need to recall the key points about the purpose of DNSSEC. DNSSEC was designed to ensure the following:

  • Origin authentication of DNS data
  • Data integrity
  • Authenticated denial of existence

DNSSEC gives DNSSEC-validating resolvers the ability to validate the authenticity of a RR received in a DNS query. If a client resolver is configured to use a DNSSEC-validating resolver and it sends a DNSSEC-enabled query (DNSSEC OK (DO) EDNS header bit) to the resolver, the validating resolver will attempt to validate the RR received in the DNS query. If the RR successfully validates, the validating resolver will return a QR to the client resolver with the "Authenticated Data (AD)" flag set. However, if the DNSSEC-enabled validating resolver fails to validate the RR, it will respond to the client resolver with a "SERVFAIL" QR. It should be noted that "SERVFAIL" is a generic DNS QR error message and does not indicate whether the underlying problem is due to a DNSSEC issue.

An essential requirement in the previous paragraph is the dependency on the client resolver being configured to use a DNSSEC-validating resolver and send a DNSSEC-enabled query to the validating resolver. If the client resolver is configured to use a non-DNSSEC-validating recursive resolver ( a resolver that does not perform DNSSEC validation), a query for the RR would return a successful NOERROR QR, pending proper configuration on the client and the RR that is configured in a zone on the DNS server. Client resolvers can also send DNSSEC-validating resolvers a non-DNSSEC-enabled query to successfully resolve a RR by not setting the DO bit in the EDNS header in the query.

Figure 8 displays the question and answer to a query that was successfully validated by the client’s DNSSEC-validating recursive resolver. The authenticity of the good-A.test.dnssec-tools.org RR DNS QR is illustrated with the presence of the Authenticated Data (AD) flag, which indicates successful validation. Additionally, both the RRSIG RR and the RR of TYPE A (what was requested) are both present in the ANSWER section of the DNSSEC QR.

Figure 8. Successfully Authenticated DNSSEC Query and Response

$ ## -------------------------------------------------------------------------------
$ ## There is no need to set the dig options each time, we'll add to an environmental
$ ## variable.
$ 
$ export DIGOPTS="+multiline +bufsize=4096 +time=3 +tries=2 +retry=0 +nosearch +ignore 
+fail +nocmd +nostats +nottlid"
$ 
$ ## -------------------------------------------------------------------------------
$ ## Successful DNSSEC-enabled query and QR with the RR being validated as indicated
$ ## by the 'ad' Flag.
$ 
$ dig ${DIGOPTS} +dnssec @149.20.64.20 good-A.test.dnssec-tools.org a
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44907
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;good-A.test.dnssec-tools.org. IN A
;; ANSWER SECTION:
good-A.test.dnssec-tools.org. IN A 75.119.216.33 good-A.test.dnssec-tools.org. IN RRSIG A 5 
4 86400 20110304134513 ( 20110202134513 19442 test.dnssec-tools.org. vpnPOgrwTs+F6B1vi/pBFFbAmcHOuImq/phJm6bUZ7XR
 2khDYlVFg5+QcuMY8WGTzTIBMRXDh2eS/6LDsIhhGXVe U9wR/KwPm4Oaf2noU3uupZ23qBocQyVoEgSVqtUHPUkp 
DI1P7doVLAaGWvxFyBm1r401W+G6hqhoy+ITLQk= )
;; AUTHORITY SECTION:
test.dnssec-tools.org.	IN NS	dns1.test.dnssec-tools.org.
test.dnssec-tools.org.	IN NS	dns2.test.dnssec-tools.org.
test.dnssec-tools.org.	IN RRSIG NS 5 3 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				Ml6R9DkmCcgJMagt92n2Pkm21Q1Z2eVKD82FVuZVJRsB
				FMj4TefLlh31xnjDdMPVpSpcq4dtA9WrNHIlISt5AoGx
				b18nPuyispJtA2Zs3Jv0WxBQXdKivV4WyxnTTvC0JvAc
				gcEWZHBNnsua2iBjeyKs0EOCC06GYdoyyHDXD+o= )
;; ADDITIONAL SECTION:
dns1.test.dnssec-tools.org. IN A 168.150.236.43
dns2.test.dnssec-tools.org. IN A 99.65.74.145
dns1.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				0R7gUh21+4jWWYbqVPH/FeT2WmhZnF5CtO8Jvdp9WyF5
				Un+EkLCMiR5nqHM4YG9Kg3UNv4EJxtgTCUw/loJ1u+dN
				cwGMn4JYj+7073WZKoLRRLowQ+A/dCZyuMFZN3KRQ4Wz
				l4PAEE2UMy9zP377fvyKPNR2ujovPSECm1mP4qg= )
dns2.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				fX/vZP9wr49xxl68dFaTBzHAur6kWV8T9HvUtPIrhOas
				4n+J9sqHH0rMgnZz5JABPBLEa4Pep9G5I/8vjfiWny71
				Vwd5AvFvupDVF/4zBeyGwJjqz2LicMlk/kJF8iQg6l+C
				PzNRWIWNbH9eqI1O9Y7SQnhsdYfT+S0dUamurHw= )
$

Some common issues observed with DNSSEC are included in the list that follows. The * character indicates that the item will be addressed in this document.

  • Larger DNS message sizes *
  • Validation failures *
  • KSK rollover and management
  • Time issues
  • Expiration of Signatures *
  • Increased usage of TCP
  • DNS software bugs
  • Devices that inspect and or alter DNS messages (for example, firewalls) *
  • Increased memory and disk usage

Troubleshooting was performed using Internet Systems Consortium, Inc., (ISC) dig utility,  DNS Operations, Analysis, and Research Center (DNS-OARC), Open DNSSEC Validating Resolver (ODVR), and DNS Reply Size Test Server services.

Larger DNS Message Sizes

As previously mentioned, packet sizes with DNSSEC will be larger than DNS without DNSSEC. The size difference is managed with the help of the EDNS. It is critical to understand RFC 1035 (Section 2.3.4. Size Limits) because this RFC describes the legacy limit for a DNS message size sent over UDP to be 512 bytes, while DNSSEC messages can easily range up to 2000 bytes in size. Many intermediate devices will inspect a DNS message for size. If the message is greater than 512 bytes, the device will drop the message and resolution may fail. Common devices that inspect DNS messages for size include firewalls, load-balancers, SOHO routers, NAT devices, etc. For the DNSSEC validating resolver to effectively process a DNSSEC QR message, you need to ensure that the path between your resolver and resolvers upstream permit DNS messages with the OPT RR present and the EDNS flag set, as well as the ability to process a DNSSEC RR with a possible size of 4096 bytes in length.

The first troubleshooting example that we will cover is to determine the size of the DNS query response message that is permitted between the client's recursive resolver and OARC's DNS Reply Size Test Server.

Note: The IPv4 or IPv6 address listed prior to DNS reply size limit is at least in the output below is the source address in the Query message when received by the DNS-OARC Reply Size Test Server. If the recursive resolver sits behind a NAT device, or a load-balancer, or some other type of intermediate device such as a firewall this could provide additional awareness whether a problem could be limitation of that device and not the resolver itself. By default dig will use the resolvers in "/etc/resolv.conf" and the resolver can be changed using the @<server> option of dig.

The ideal DNS QR message reply size limit should be larger than 4,000 bytes to effectively support DNSSEC; however, if the DNS QR message is smaller than 4,000 bytes, it is recommended that you investigate whether the problem is lack of support for EDNS (for example ("lacks EDNS, defaults to 512"), IP fragments being filtered, the message was truncated and sent via TCP and then retrying in TCP mode, etc. Additional information about the DNS-OARC Reply Size Test Server is available at the following link: https://www.dns-oarc.net/oarc/services/replysizetest. The outputs from running the dig utility are shown in Figure 9.

Figure 9. Sample Output from dig Utility

$ ## -------------------------------------------------------------------------------
$ ## There is no need to set the dig options each time, we'll add to an environmental
$ ## variable.
$ 
$ export DIGOPTS="+multiline +bufsize=4096 +time=3 +tries=2 +retry=0 +nosearch +ignore 
+fail +nocmd +nostats +nottlid"
$ 
$ ## -------------------------------------------------------------------------------
$ ## Output indicates a good path between the resolver and DNS-OARC Reply Size Server.
$ 
$ dig +short @192.0.2.1 rs.dns-oarc.net txt
rst.x4091.rs.dns-oarc.net.
rst.x3837.x4091.rs.dns-oarc.net.
rst.x3843.x3837.x4091.rs.dns-oarc.net.
"192.0.2.1 sent EDNS buffer size 4096" "192.0.2.1 DNS reply size limit is at least 4091" "Tested at 2011-01-11 07:46:10 UTC"
$ 
$ dig +short @2001:db8::abc rs.dns-oarc.net txt
rst.x4091.rs.dns-oarc.net.
rst.x4049.x4091.rs.dns-oarc.net.
rst.x4055.x4049.x4091.rs.dns-oarc.net.
"2001:db8::a sent EDNS buffer size 4096" "2001:db8::a DNS reply size limit is at least 4091" "Tested at 2011-01-11 07:48:07 UTC"
$ 
$ ## -------------------------------------------------------------------------------
$ ## Output indicates a good EDNS buffer advertised to the DNS-OARC Reply Size Server;
$ ## however, the accepted DNS QR message size of the was limited to 490 bytes. This
$ ## could indicate some type of filtering and/or intermediate device like a firewall.
$ ## This issue should be investigated to determine the reason for the limited size of
$ ## DNS QR message.
$ 
$ dig +short @192.0.2.1 rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x450.x476.rs.dns-oarc.net.
rst.x490.x450.x476.rs.dns-oarc.net.
"192.0.2.1 sent EDNS buffer size 4096" "192.0.2.1 DNS reply size limit is at least 490" "Tested at 2011-01-11 08:18:39 UTC"
$ 
$ ## -------------------------------------------------------------------------------
$ ## Output indicates that EDNS was not used (lacks EDNS, defaults to 512) and that is
$ ## reflected in the size of the DNS QR message - which is limited to a length of 490
$ ## bytes.
$ 
$ dig +short @192.0.2.1 rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"192.0.2.1 lacks EDNS, defaults to 512" "192.0.2.1 DNS reply size limit is at least 490" "Tested at 2011-01-11 08:30:45 UTC"
$ 
$ ## -------------------------------------------------------------------------------
$ ## Output indicates a good path between the resolver and DNS-OARC Reply Size Server;
$ ## however, it should be noted that the DNS QR message was Truncated. This may occur
$ ## because certain resolvers my send the full authority section in the DNS QR message
$ ## and dig does not advertise an EDNS receive buffer. The receive buffer for dig can
$ ## be advertised using the +bufsize=<size> option.
$ 
$ dig +short @2001:db8::def rs.dns-oarc.net txt
;; Truncated, retrying in TCP mode.
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"2001:db8::def sent EDNS buffer size 4096" "2001:db8::def DNS reply size limit is at least 3843" "Tested at 2011-01-11 09:40:18 UTC"
$

Validation Failures

Validation failures may occur for various reasons, including the following:

  • Bad signature, or the signature has expired or is for the future
  • Bad data in the RR
  • Keys reference keys that do not exist (for example, DS key references a DNSKEY that does not exist in the currently served zone data)
  • Lack of a signature for a signed zone

In this section, we will troubleshoot some of the common validation failures using the DNSSEC-Tools Project Test Zone and DNS OARC Open DNSSEC Validating Resolver service.

Note: When troubleshooting validation failures, setting the Checking Disabled (CD) flag can provide added visibility because it informs the recursive DNSSEC-validating resolver to disable signature validation of an RR for the submitted query. If the DNS QR result status is NOERROR (successful), the output should include the RR type (if present) for the query request along with the RRSIG RRs for the queried RR; this typically indicates a validation failure, which can occur due to the varying reasons previously mentioned. Setting the CD flag for a DNS query request can also provide visibility into the size of the DNS QR as well.

Figure 10. Example of Troubleshooting DNSSEC Validation Failures

$ ## -------------------------------------------------------------------------------
$ ## There is no need to set the dig options each time, we'll add to an environmental
$ ## variable.
$ 
$ export DIGOPTS="+multiline +bufsize=4096 +time=3 +tries=2 +retry=0 +nosearch +ignore 
+fail +nocmd +nostats +nottlid"
$ 
$ ## -------------------------------------------------------------------------------
$ ## Initial query for the "addedlater-nosig-A.test.dnssec-tools.org" record does not
$ ## validate because the record was added to the zone after the zone was signed.
$ 
$ dig ${DIGOPTS} +dnssec @149.20.64.20 addedlater-nosig-A.test.dnssec-tools.org a
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51476
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;addedlater-nosig-A.test.dnssec-tools.org. IN A
$ 
$ ## -------------------------------------------------------------------------------
$ ## To ensure we can receive the RR for "addedlater-nosig-A.test.dnssec-tools.org",
$ ## we will set the "CD" flag in the DNS query which informs the DNSSEC validating
$ ## resolver to disable signature validation of an RR for a query. The following
$ ## output illustrates that we can receive the record but it is not authenticated.
$ ## What is additionally important to note is that an RRSIG for this record does not
$ ## exist which is why the resolver failed to validate it; no signature to verify.
$ 
$ dig ${DIGOPTS} +cdflag +dnssec @149.20.64.20 addedlater-nosig-A.test.dnssec-tools.org a
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43808
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;addedlater-nosig-A.test.dnssec-tools.org. IN A
;; ANSWER SECTION:
addedlater-nosig-A.test.dnssec-tools.org. IN A 75.119.216.33
;; AUTHORITY SECTION:
test.dnssec-tools.org.	IN NS	dns2.test.dnssec-tools.org.
test.dnssec-tools.org.	IN NS	dns1.test.dnssec-tools.org.
test.dnssec-tools.org.	IN RRSIG NS 5 3 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				Ml6R9DkmCcgJMagt92n2Pkm21Q1Z2eVKD82FVuZVJRsB
				FMj4TefLlh31xnjDdMPVpSpcq4dtA9WrNHIlISt5AoGx
				b18nPuyispJtA2Zs3Jv0WxBQXdKivV4WyxnTTvC0JvAc
				gcEWZHBNnsua2iBjeyKs0EOCC06GYdoyyHDXD+o= )
;; ADDITIONAL SECTION:
dns1.test.dnssec-tools.org. IN A 168.150.236.43
dns2.test.dnssec-tools.org. IN A 99.65.74.145
dns1.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				0R7gUh21+4jWWYbqVPH/FeT2WmhZnF5CtO8Jvdp9WyF5
				Un+EkLCMiR5nqHM4YG9Kg3UNv4EJxtgTCUw/loJ1u+dN
				cwGMn4JYj+7073WZKoLRRLowQ+A/dCZyuMFZN3KRQ4Wz
				l4PAEE2UMy9zP377fvyKPNR2ujovPSECm1mP4qg= )
dns2.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				fX/vZP9wr49xxl68dFaTBzHAur6kWV8T9HvUtPIrhOas
				4n+J9sqHH0rMgnZz5JABPBLEa4Pep9G5I/8vjfiWny71
				Vwd5AvFvupDVF/4zBeyGwJjqz2LicMlk/kJF8iQg6l+C
				PzNRWIWNbH9eqI1O9Y7SQnhsdYfT+S0dUamurHw= )
$ 
$ ## -------------------------------------------------------------------------------
$ ## Since the record in this request indicates that it does not have a signature, we
$ ## can explicitly request for the DNS RRSIG RR which contains the signature used to
$ ## validate the authenticity of the RR for the DNSSEC signed zone. If the zone is
$ ## signed, then the RR should have a signature for the record. As we can see here,
$ ## an RRSIG does not exist which further confirms the lack of a signature for this A
$ ## record.
$ 
$ dig ${DIGOPTS} +cdflag +dnssec @149.20.64.20 addedlater-nosig-A.test.dnssec-tools.org 
rrsig
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48941
;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;addedlater-nosig-A.test.dnssec-tools.org. IN RRSIG
;; AUTHORITY SECTION:
test.dnssec-tools.org.	IN NS	dns1.test.dnssec-tools.org.
test.dnssec-tools.org.	IN NS	dns2.test.dnssec-tools.org.
test.dnssec-tools.org.	IN RRSIG NS 5 3 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				Ml6R9DkmCcgJMagt92n2Pkm21Q1Z2eVKD82FVuZVJRsB
				FMj4TefLlh31xnjDdMPVpSpcq4dtA9WrNHIlISt5AoGx
				b18nPuyispJtA2Zs3Jv0WxBQXdKivV4WyxnTTvC0JvAc
				gcEWZHBNnsua2iBjeyKs0EOCC06GYdoyyHDXD+o= )
;; ADDITIONAL SECTION:
dns1.test.dnssec-tools.org. IN A 168.150.236.43
dns2.test.dnssec-tools.org. IN A 99.65.74.145
dns1.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				0R7gUh21+4jWWYbqVPH/FeT2WmhZnF5CtO8Jvdp9WyF5
				Un+EkLCMiR5nqHM4YG9Kg3UNv4EJxtgTCUw/loJ1u+dN
				cwGMn4JYj+7073WZKoLRRLowQ+A/dCZyuMFZN3KRQ4Wz
				l4PAEE2UMy9zP377fvyKPNR2ujovPSECm1mP4qg= )
dns2.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				fX/vZP9wr49xxl68dFaTBzHAur6kWV8T9HvUtPIrhOas
				4n+J9sqHH0rMgnZz5JABPBLEa4Pep9G5I/8vjfiWny71
				Vwd5AvFvupDVF/4zBeyGwJjqz2LicMlk/kJF8iQg6l+C
				PzNRWIWNbH9eqI1O9Y7SQnhsdYfT+S0dUamurHw= )
$ 
$ ## -------------------------------------------------------------------------------
$ ## The following examples will also perform the same tests as per the previous but
$ ## the signature (RRSIG) does exist for the RR. The signature 'RRSIG' for Example
$ ## #1 is bad and the 'RR data' for Example #2 is bad. In each example output, the
$ ## first execution of dig will fail with a SERVFAIL QR which is expected since the
$ ## signature is bad for Example #1 and the RR data is bad for Example #2. Then the
$ ## execution of dig will succeed because the +cdflag is set in the DNS query.
$ ##
$ ## -------------------------------------------------------------------------------
$ ## Example #1, first execution: SERVFAIL due to a bad signature
$ 
$ dig ${DIGOPTS} +dnssec @149.20.64.20 badsign-A.test.dnssec-tools.org a
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15961
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;badsign-A.test.dnssec-tools.org. IN A
$ 
$ ## -------------------------------------------------------------------------------
$ ## Example #1, second execution: NOERROR due to use of the +cdflag
$ 
$ dig ${DIGOPTS} +cdflag +dnssec @149.20.64.20 badsign-A.test.dnssec-tools.org a
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40573
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;badsign-A.test.dnssec-tools.org. IN A
;; ANSWER SECTION:
badsign-A.test.dnssec-tools.org. IN A 75.119.216.33 badsign-A.test.dnssec-tools.org.
 IN RRSIG A 5 4 86400 20110304134513 ( 20110202134513 19442 test.dnssec-tools.org. 
aTK5H+fgtJUQugi7GIXYwSrbh8WxDC3Hy0gFerd3DL1M XLZ/Fgd/8mQJOAcfj9FuUsMm1O81WmNQKqhDDGVtXcHS 
ZlWxqTX1rCxwxgiUwOZYXuMg6I5Y73XJl2boy3AAo7qV jwRJr5HnTsc1xklA5thv/1pvAtPisI3KuPz71lM= )
;; AUTHORITY SECTION:
test.dnssec-tools.org.	IN NS	dns1.test.dnssec-tools.org.
test.dnssec-tools.org.	IN NS	dns2.test.dnssec-tools.org.
test.dnssec-tools.org.	IN RRSIG NS 5 3 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				Ml6R9DkmCcgJMagt92n2Pkm21Q1Z2eVKD82FVuZVJRsB
				FMj4TefLlh31xnjDdMPVpSpcq4dtA9WrNHIlISt5AoGx
				b18nPuyispJtA2Zs3Jv0WxBQXdKivV4WyxnTTvC0JvAc
				gcEWZHBNnsua2iBjeyKs0EOCC06GYdoyyHDXD+o= )
;; ADDITIONAL SECTION:
dns1.test.dnssec-tools.org. IN A 168.150.236.43
dns2.test.dnssec-tools.org. IN A 99.65.74.145
dns1.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				0R7gUh21+4jWWYbqVPH/FeT2WmhZnF5CtO8Jvdp9WyF5
				Un+EkLCMiR5nqHM4YG9Kg3UNv4EJxtgTCUw/loJ1u+dN
				cwGMn4JYj+7073WZKoLRRLowQ+A/dCZyuMFZN3KRQ4Wz
				l4PAEE2UMy9zP377fvyKPNR2ujovPSECm1mP4qg= )
dns2.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				fX/vZP9wr49xxl68dFaTBzHAur6kWV8T9HvUtPIrhOas
				4n+J9sqHH0rMgnZz5JABPBLEa4Pep9G5I/8vjfiWny71
				Vwd5AvFvupDVF/4zBeyGwJjqz2LicMlk/kJF8iQg6l+C
				PzNRWIWNbH9eqI1O9Y7SQnhsdYfT+S0dUamurHw= )
$ 
$ ## -------------------------------------------------------------------------------
$ ## Example #2, first execution: SERVFAIL due to a bad RR data
$ 
$ dig ${DIGOPTS} +dnssec @149.20.64.20 baddata-A.test.dnssec-tools.org a
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46821
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;baddata-A.test.dnssec-tools.org. IN A
$ 
$ ## -------------------------------------------------------------------------------
$ ## Example #2, second execution: NOERROR due to use of the +cdflag
$ 
$ dig ${DIGOPTS} +cdflag +dnssec @149.20.64.20 baddata-A.test.dnssec-tools.org a
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60845
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;baddata-A.test.dnssec-tools.org. IN A
;; ANSWER SECTION:
baddata-A.test.dnssec-tools.org. IN A 75.119.216.30 baddata-A.test.dnssec-tools.org.
 IN RRSIG A 5 4 86400 20110304134513 ( 20110202134513 19442 test.dnssec-tools.org. 
ouQRusF4ruNy5mDJSA61d6tS5Qe5VyfHavjDNFAE7UWK wUKUJgNhCHdZzDFrTeinbc8YpP85xrylEbRQyIrYlu8c 
p0ypEcEKilrs6SJq1B9mPMKmp7Oem72Bpkpe0FdRTt6A e3eqAiCJs0ZuOITJVZ8pegiZWgUKcp/+rI6LSmw= )
;; AUTHORITY SECTION:
test.dnssec-tools.org.	IN NS	dns1.test.dnssec-tools.org.
test.dnssec-tools.org.	IN NS	dns2.test.dnssec-tools.org.
test.dnssec-tools.org.	IN RRSIG NS 5 3 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				Ml6R9DkmCcgJMagt92n2Pkm21Q1Z2eVKD82FVuZVJRsB
				FMj4TefLlh31xnjDdMPVpSpcq4dtA9WrNHIlISt5AoGx
				b18nPuyispJtA2Zs3Jv0WxBQXdKivV4WyxnTTvC0JvAc
				gcEWZHBNnsua2iBjeyKs0EOCC06GYdoyyHDXD+o= )
;; ADDITIONAL SECTION:
dns1.test.dnssec-tools.org. IN A 168.150.236.43
dns2.test.dnssec-tools.org. IN A 99.65.74.145
dns1.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				0R7gUh21+4jWWYbqVPH/FeT2WmhZnF5CtO8Jvdp9WyF5
				Un+EkLCMiR5nqHM4YG9Kg3UNv4EJxtgTCUw/loJ1u+dN
				cwGMn4JYj+7073WZKoLRRLowQ+A/dCZyuMFZN3KRQ4Wz
				l4PAEE2UMy9zP377fvyKPNR2ujovPSECm1mP4qg= )
dns2.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110304134513 (
				20110202134513 19442 test.dnssec-tools.org.
				fX/vZP9wr49xxl68dFaTBzHAur6kWV8T9HvUtPIrhOas
				4n+J9sqHH0rMgnZz5JABPBLEa4Pep9G5I/8vjfiWny71
				Vwd5AvFvupDVF/4zBeyGwJjqz2LicMlk/kJF8iQg6l+C
				PzNRWIWNbH9eqI1O9Y7SQnhsdYfT+S0dUamurHw= )
$ 
$ ## -------------------------------------------------------------------------------
$ ## RR signatures are valid for a lifetime that is defined by the zone administrator.
$ ## The valid lifetime of a signature for an RR is inserted into the RRSIG RR and the
$ ## signature is created by signing the RR for a domain using the zones DNSKEY. The
$ ## DNSKEY RR contains the crypto key used to sign records for a zone. The DNSKEY RR
$ ## can contain either the Key Signing Key (KSK) or the Zone Signing Key (ZSK).
$ ##
$ ## The following examples will show you how to troubleshoot a signature which has
$ ## expired (is for a lifetime that is valid in the past) and for signatures that are
$ ## not valid yet as the signature is valid for a lifetime that exists in the future.
$ ##
$ ## -------------------------------------------------------------------------------
$ ## The following examples show how to determine the current lifetime for the RRSIG
$ ## RR of the SOA RR and the KSK or ZSK by requesting the DNSKEY RR:
$ 
$ dig ${DIGOPTS} +nomultiline +noadd +noauth +cdflag +dnssec @149.20.64.20 test.dnssec-
tools.org soa | gawk '/RRSIG/{if ($3=="RRSIG") {print "signature lifetime is valid from: " 
$9" - "$8}}'
signature lifetime is valid from: 20110202134513 - 20110304134513
$ 
$ dig ${DIGOPTS} +nomultiline +noadd +noauth +cdflag +dnssec @149.20.64.20 test.dnssec-
tools.org soa | egrep RRSIG
test.dnssec-tools.org.	IN	RRSIG SOA 5 3 600 20110304134513 20110202134513 19442 
test.dnssec-tools.org. NoSCt9SgyMTIHueclvTGOoy2LSXg/Uxt2rteSkm97F8xODxt48FMhF0X 
phQsHuQXZHdtg9TdsypBckH5CAdyn9dIEVNzQ2QkhMjjc/BFipO6rRBq 
lmQLMgAnM9K+kxRM6aV69ZuWwVClQnsH0vMBI4F/XN5tCVhsCybR3jiC +kg=
$ 
$ dig ${DIGOPTS} +nomultiline +noadd +noauth +cdflag +dnssec @149.20.64.20 test.dnssec-
tools.org dnskey | egrep RRSIG
test.dnssec-tools.org.	IN	RRSIG DNSKEY 5 3 86400 20110304134513 20110202134513 
19442 test.dnssec-tools.org. xBH+g4nAs+37wB/rjM280FIcYx2CftH/DQNpuEIKyU4m8DMBHmCG2c/r 
HWcg5TSdzt4a35K28Oz6eY0+1Rr5rtC+ouTyBTb+p8jQDp+JVeEj09y0 
cTGnLwIOhUjdP5R8NBTDGy9P8WcvYUREZ+4KYYk0oJ7r2N+37bC9yy9P ihU=
test.dnssec-tools.org.	IN	RRSIG DNSKEY 5 3 86400 20110304134513 20110202134513 
28827 test.dnssec-tools.org. QtAsYbd8l4tqErDDrss+xzQpxWP4e1VQAUb+60mJdcAYJiZqu32evMNg 
Lv21FkOEQoCCKK6PpmpTWV0KcvWiFHUwCOd2+p32kFzeXroAIpkb6Hxx 
cIDkVKDw8+itpwW+qqLtsmtBgogP0C9nYSjQTRv4ofvf9JovyxQesnAW 
Dg1vFLK0sqjAAmAwfUAQ8frDceFiEwMV7nSzjfmSH+Ol8UAXgRoJXsQH 
lqdTFrl9iG//F76m7ZwSmLtGS7u33Zncn3lZAyk3iAnWQPC+xmq1GJTM 
SrRAy3zlSmpo0vzrJROSGRDzVtMhaNThFRmjvtexz5mXJ8VfqVQCFBgF nhLNDVna5Tl/uWLLWg9D1aM4CTyV19Fh
/yHgMw9VwMVAaJp/KDzSGB/X yhpAzSibZq3xFgzC5wZ4h9F7b6sBWxyhY0GH4sxsIap2R1FsLCyPaZXm 
yPA5guDKTqAHSH1ubmvKcLG8qkv9lAn/aRjQfXV+HVQbFVJt2GzKgcqn 
J+smhPkNmQDldEn4OiVwddYANWvpbNxYlidUmjZ85Ok7YmV3nLcG/5ot 
Gqkjx3WasUz9nRKdlQpzBItSTRy7yekUg/XtCqpt5zBsGp6MjcrF9ErT 
h3DqeWkkRR64yTs3JQYUu9NQBSuPI5SAAtbumgmmGls6VB5AG6uxjyih l9nEDgiapfE=
test.dnssec-tools.org.	IN	RRSIG DNSKEY 5 3 86400 20110304134513 20110202134513 
55926 test.dnssec-tools.org. Mc+AZex5rGv01g1tDQ4sAXPKppGHoCLG7SDjcBvC3+r66AzuGD2zPjfp 
fm38R+7un2+5VrjaBg1eH85UbwNy0tWtvEKGvQxRFhHI0k0QgdYg/
Y2D 4j/YHdgVGSngCuMHpUA0f86EAE+ZcXjSEbsIH1yRWhBWwh/V0Y4jDHR/ 
HOqNPApHO8aXYZN9Gig4OUbpNp/21udJCV9OcN9E/2SW1Yy/ImOAmaLv 
c2a7NQiSWI3YfDntrf+QoeYNanhrvUsioWw0NSWeG0MONlIu5OD5aB1p 
nTbCxGyU04zVFsaS3FD16MyhxngoUjWiMxnhu9gt6tQruagFbFRFB0kL dRUnsQ==
$ 
$ ## -------------------------------------------------------------------------------
$ ## The three examples that follow show how to determine the current lifetime of an
$ ## RRSIG RR that is expired, for a lifetime in the future, and current lifetime of
$ ## the ZSK, which would be a valid signature (pending the other data for the RR is
$ ## good and results in successful validation).
$ ##
$ ## Example output #1: Signature is valid for a lifetime in the future and this RR
$ ## would fail validation.
$ 
$ dig ${DIGOPTS} +nomultiline +noadd +noauth +cdflag +dnssec @149.20.64.20 futuredate-
A.test.dnssec-tools.org a | egrep RRSIG
futuredate-A.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110503074514 20110403074514 
19442 test.dnssec-tools.org. Gdo9KStkxAtHMLO732M9L4vVYSymZXfl9w5SK67wYhsZdqdksiPuOt0g 
Y0FFPatgwvHf+ghTnKuNW5lCbmJ8o0ZpUGofdUxjCw3I4MIaJ7iD4s70 
ZBlTYKRwQ7LHWw5kNwIncTBE6SyXwk8LOv7/wNWvzPHguhAGfzCzZLLY QHk=
$ 
$ ## Example output #2: Signature is expired for the current ZSK lifetime and this RR
$ ## would fail validation.
$ 
$ dig ${DIGOPTS} +nomultiline +noadd +noauth +cdflag +dnssec @149.20.64.20 pastdate-
A.test.dnssec-tools.org a | egrep RRSIG
pastdate-A.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110202064014 20110103064514 19442 
test.dnssec-tools.org. XB9LRG4lAk6rw0HhjUazPkaYFcYCLlDh1ILlC3Jm/f6YQOdZo0YRr9JV 
vH+ddNJhWSaNQ0d4CnWIS/g6DP+AvDeNN755jqfGF5aFiwSJ387KRhee /hxrLnJNN0EeGo4V2OYA8ads+rV+7f
/TiEdJ66dQdmBgWjDhtV945Qlx XlU=
$ 
$ ## Example output #3: Signature is value for the current ZSK lifetime and this RR
$ ## would successfully pass the validation check.
$ 
$ dig ${DIGOPTS} +nomultiline +noadd +noauth +cdflag +dnssec @149.20.64.20 
good-A.test.dnssec-tools.org a | egrep RRSIG
good-A.test.dnssec-tools.org. IN RRSIG A 5 4 86400 20110304134513 20110202134513 19442 
test.dnssec-tools.org. vpnPOgrwTs+F6B1vi/pBFFbAmcHOuImq/phJm6bUZ7XR2khDYlVFg5+Q 
cuMY8WGTzTIBMRXDh2eS/6LDsIhhGXVeU9wR/KwPm4Oaf2noU3uupZ23 
qBocQyVoEgSVqtUHPUkpDI1P7doVLAaGWvxFyBm1r401W+G6hqhoy+IT LQk=
$

Devices That Inspect and Alter DNS Messages

There are software features, protocols, products and devices that range from firewalls, load-balancers, and DNS proxies to devices performing NAT that may inspect or alter the original contents of a DNS query message. With the addition of DNSSEC, devices that historically inspect legacy DNS messages may not properly process DNS messages that contain DNSSEC data, or these devices may alter the DNS message contents, which could cause DNSSEC validation failures. Additionally, many devices may still adhere to the legacy DNS maximum message length of 512 bytes for DNS messages sent over UDP. Sticking to the size limit of 512 bytes could also lead to inconsistencies in validating signed RRs: successful validation or a failed validation. Operators must ensure that the devices over which DNSSEC-enabled messages transit do not tamper with or alter the DNS message contents that could cause validation failures.  Devices must also be EDNS-aware, able to properly inspect and process DNSSEC-enabled messages, configured to permit both DNS packets sent on UDP and TCP port 53, and ensure that messages larger than 512 bytes are permitted and not dropped.

As an example, the Cisco PIX Firewall products, that have now been replaced by the Cisco Adaptive Security Appliance (ASA), would drop any DNS message larger than 512 bytes in length. If your firewall still has this DNS inspection limit enabled, you may see the log message shown in Figure 11 on your Syslog host or the logging buffer of the firewall. It should be noted that these log messages are also applicable to the Firewall Services Module (FWSM) for the Cisco Catalyst 6500 Switch and Cisco 7600 Series router.

Figure 11. Example of Troubleshooting DNSSEC Validation Failures


%ASA-4-410001: Dropped UDP DNS reply from outside:149.20.64.20/53 to Inside:10.0.1.21/56616; 
packet length 1619 bytes exceeds configured limit of 512 bytes
%ASA-4-410001: Dropped UDP DNS reply from outside:149.20.64.20/53 to Inside:10.0.1.21/56616; 
packet length 1619 bytes exceeds configured limit of 512 bytes
%ASA-4-410001: Dropped UDP DNS reply from outside:149.20.64.20/53 to Inside:10.0.1.21/56616; 
packet length 1619 bytes exceeds configured limit of 512 bytes

Guidance on device configuration recommendations is available in the Preparing Your Network section of this white paper.

Additional Tools for Troubleshooting DNSSEC

VeriSign Labs: DNSSEC Debugger http://dnssec-debugger.verisignlabs.com/

The DNSSEC Debugger from VeriSign Labs is an online tool to assist with diagnosing problems with DNSSEC-signed names and zones.

VeriSign Labs: YAZVS – Yet Another Zone Validation Script http://yazvs.verisignlabs.com/

yazvs.pl is one of the utilities that VeriSign uses daily to validate new versions of the root and arpa zones before they are published to the distribution masters. It performs the following steps:

  1. Read a candidate zone file from disk
  2. Validate KSKs using a locally configured trust anchor
  3. Validate ZSKs using KSKs
  4. Validate RRSIGs using ZSKs
  5. Retrieve the current zone data via AXFR
  6. Print a summary of the number of KSKs, ZSKs, DS, and RRSIG records that have changed
  7. Optionally produce a Unix diff of the two zones, excluding RRSIG/NSEC/NSEC3 records

Sandia National Laboratories: DNSViz http://dnsviz.net/

DNSViz is a tool for visualizing the status of a DNS zone. It was designed as a resource for understanding and troubleshooting deployment of the DNS Security Extensions (DNSSEC). It provides a visual analysis of the DNSSEC authentication chain for a domain name and its resolution path in the DNS namespace, and it lists configuration errors detected by the tool.

SURFnet: DNSSEC Checker http://www.dnssecmonitor.org/

The DNSSEC Checker is a python script that has been created to be used within nagios 3.x, as standalone or can be used integrated in a webpage. The chain validation uses the binaries of unbound-host, which can use a running instance of unbound to enable caching to speed up the process. Other checks make use of the dnspython module to handle DNS packets with EDNS.

UCLA University: SecSpider the DNSSEC Monitoring Project http://secspider.cs.ucla.edu/

.SE: DNSCheck http://dnscheck.iis.se/

DNSCheck is a program that was designed to help people check, measure, and understand the workings of the DNS. When a domain (zone) is submitted to DNSCheck, it will investigate the domain's general health by traversing the DNS from root (.) to the TLD (Top Level Domain, such as.SE) to eventually the nameserver(s) that holds the information about the specified domain (such as iis.se). Other checks, for example measuring host connectivity, validity of IP-addresses, and control of DNSSEC signatures will also be performed.

Frobbit!: DNSCHECK http://www.dnscheck.se/

DNSCHECK is a service that verifies the quality of delegations in DNS. The service should not be compared with programs that verify and check the content of a zone. DNSCHECK consists of one program that verifies the delegation, and one larger package that runs this program repeatedly and collects statistics. No regular checks of zones are done, only manual checking. And because of that, some statistics of the zone content (number of delegations, for example) might be wrong.

Conclusion

There has been a great deal of information shared regarding the deployment of DNSSEC and how it will be effective in preventing certain types of DNS-related attacks, for example, DNS cache poisoning, that are prevalent on the Internet. This white paper may assist networking staff in deploying DNSSEC more seamlessly in their network. The authors hope that the information contained in this document will help network administrators avoid some of the networking issues that may arise when DNSSEC is deployed in the network.

Acknowledgments

Authors John Stuppi (jstuppi@cisco.com) and Joseph Karpenko (jkarpenk@cisco.com) are members of the Applied Intelligence team in the Security Research & Operations organization. Andrae Middleton (amiddlet@cisco.com) of Applied Intelligence and Tim Sammut (tsammut@cisco.com) of the PSIRT also contributed to this white paper.

Additional Resources

Shareware 
http://www.freedownloadscenter.com/Utilities/System_Analysis_Utilities/Active_Registry_Monitor.html

TCPView
http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx

Microsoft Windows Debugger 
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx

References

IETF DNS Extensions (dnsext) Working Group 
http://www.ietf.org/html.charters/dnsext-charter.html, http://datatracker.ietf.org/wg/dnsext/, and http://tools.ietf.org/wg/dnsext/

ISC, Inc.: BIND
http://www.isc.org/software/bind/dnssec

ISC, Inc.: DNSSEC in 6 minutes by Alan Clegg
www.isc.org/files/DNSSEC_in_6_minutes.pdf

NLnetLabs: DNSSEC HOWTO 
http://www.nlnetlabs.nl/publications/dnssec_howto/

NLnetLabs: Unbound
http://unbound.net/ and http://www.nlnetlabs.nl/projects/unbound/

DNSSEC Protocol Resources
http://www.dnssec.net/

DNSSEC Deployment Initiative
http://www.dnssec-deployment.org/

Root DNSSEC: Information about DNSSEC for the Root Zone 
http://www.root-dnssec.org/

Root DNSSEC: DNSSEC Rollout Status
http://www.root-dnssec.org/category/status/

IANA DNSSEC Information, KSK Operator Information
https://www.iana.org/dnssec/

IANA Root DNSSEC Design Team: DNSSEC Trust Anchor Publication for the Root Zone
http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html

Sparta, Inc.: The DNSSEC-Tools Project
http://www.dnssec-tools.org/

Sparta, Inc.: The DNSSEC-Tools Project: DNSSEC-Tools Package
https://www.dnssec-tools.org/wiki/index.php/DNSSEC-Tools_Components

Sparta, Inc.: The DNSSEC-Tools Project: Test Zone
http://www.dnssec-tools.org/testzone/

ARIN DNSSEC Deployment Plan
https://www.arin.net/resources/dnssec/index.html

ICANN DNS Operations
http://dns.icann.org/

ICANN DNS Operations, Root DNSSEC
http://dns.icann.org/ksk/

DNS Operations, Analysis, and Research Center (DNS-OARC)
https://www.dns-oarc.net/

DNS Operations, Analysis, and Research Center (DNS-OARC): Open DNSSEC Validating Resolver
https://www.dns-oarc.net/oarc/services/odvr

DNS Operations, Analysis, and Research Center (DNS-OARC): DNS Reply Size Test Server
https://www.dns-oarc.net/oarc/services/replysizetest

Wikipedia: Domain Name System Security Extensions
http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

 

This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.

Back to Top