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
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:
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
To understand the DNS and the DNS-specific recommendations in this document, operators and administrators should be familiar with the following terms:
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:
A summary of the three examples follows:
Additional information is available in DNS Best Practices, Network Protections, and Attack Identification.
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.
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.
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.
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:
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
!
|
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.
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.
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.
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
!
|
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.
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.
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:
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.
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:
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.
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.
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.
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.
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:
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 |
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.
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.
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 |
Validation Failures
Validation failures may occur for various reasons, including the following:
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 |
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; |
Guidance on device configuration recommendations is available in the Preparing Your Network section of this white paper.
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:
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.
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.
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.
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
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.