DNSSEC Frequently Asked Questions (and a few Frequently Heard Myths)
Below is a list of frequently asked questions about DNSSEC and its deployment with some answers. Often these answers only scratch the surface and links to more relevant information is included whenever possible.
Also below are some frequently heard statements that misunderstand a feature of the DNSSEC specification or impact of DNSSEC on an organization's DNS infrastructure. The answers given to these statements are a response to these statements and include information (where possible) addressing the perceived problem and the solution space.
General Questions
The current specification of DNSSEC is inoperable with earlier versions
DNSSEC will require a total re-engineering of an organization's DNS from the ground up.
Performance Issues
Longer resolutions time now that validators are building chains of authentication.
DNSSEC responses are too large, and will truncate messages or require TCP.
Key Distribution Issues
Zone Enumeration
Hardware/Software and Infrastructure Issues
- There is no products that do DNSSEC
- Applications don't support it and will not work with DNSSEC
- There is no support for DNSSEC in hardware/firmware
- DNSSEC will not work with load balancing systems
- Will DNSSEC ever be implmented as part of Microsoft Server?
- Why deploy when the root isn't signed?
- We need to wait for our parent to sign first.
General Questions/Myths
The current specification of DNSSEC is inoperable with earlier versions
True. However, all current implementations developed after the final specification was published (2005) implement the current version. There are no known deployments that implement the earlier specification of DNSSEC (as outlined in the now obsolete RFC 2535).
DNSSEC will require a total re-engineering of an organization's DNS from the ground up.
Not for every deployment. DNSSEC does add new considerations and requires new operational practices, but to what extent an organization's infrastructure will need to be re-engineered depends on the current operation.
DNSSEC will require new DNS related operations (e.g. key generation and storage, zone signing, etc.) as well as changes to existing operations (e.g. resigning after adding a new DNS entry, etc.). Each organization maintains their DNS in a unique way, so each organization will have to develop their own procedures for deploying DNSSEC based on current operations, documented best practices and any external regulations that may dictate certain deployment choices.
My websites aren't famous enough to be poisoned
DNSSEC covers all DNS data, not just the name to address translation for web servers. DNSSEC is designed to protect all client communications that use DNS data in some way such as voice over IP (VoIP), email, chat protocols, etc. as well as HTTP communications.
No need for DNSSEC if you use IPv6
IPv6 does not provide protection for newly discovered hosts. Setting up IPsec (a component to IPv6) some overhead work that could make DNS transactions take too long to complete compared to today. DNSSEC relies on a pre-established trust hierarchy inherent to the DNS and caching to speed lightweight validation of DNS data.
My architecture is handled by ACLs
ACL’s may provide some protection for internal clients going out, as long as the number of servers they contact on the outside remains limited. It does not protect outside (not part of your organization) from DNS poisoning and does not protect against cache poisoning by man-in-the-middle attacks.
It's too complex
Does it work correctly?The latest version of the DNS Security Extensions (published in 2005) has been successfully deployed in numerous production zones including ccTLDs. It has been extensively tested by these operators as well as in independent workshops.
Several organizations have developed tools to simplify DNSSEC management. Ranging from wrappers around the tools found in BIND all the way to complete turnkey solutions for DNSSEC. A partial list is available on the DNSSEC Deployment Initiative webpage and DNSSEC.net
Performance Issues
My zone will grow too large to run on my servers
Studies have show that zones do grow larger, but standard servers still have enough memory to serve all by the largest zones. A zone with 30,000 unique RRs only grows to 27-35MB depending on the size of the key used to generate signatures. Well within the performance range of today’s servers. More information can be found at NIST DNSSEC Performance Page.
My servers won’t be able to generate signatures fast enough
In DNSSEC, signatures are generated prior to serving (that is, offline). DNS servers do not do any signature generation unless they are updated via dynamic update. If dynamic update is used, standard implementations will only sign the zone changes, not the entire zone, making signed updates appear quickly.
DNSSEC can’t be used with dynamic update
DNSSEC can be used with dynamic update, as long as the signing key is on the server. When the update message is sent, the server generates signatures only over those RRsets that have changed. This may be up to 4 signatures for a dynamic update: (1 for the changed RRset, 2 for the NSEC RRs changed, and 1 for the SOA which has an updated serial number). Securing communication between a DHCP server and a DNS server has been tested and proven to work.
My network connection is too small to use DNSSEC
DNSSEC enabled responses are only returned when requested. Currently, since DNSSEC is not in every client – this traffic will be in the minority. Previous has shown that the ammount of bandwidth used by DNS will increase depending on the number of clients requesting DNSSEC responses. How much of an impact seen by an organization depends on the ammount of DNS traffic seen today, and what percentage of users will request DNSSEC signed responses.
My cache size will grow out of control
This depends on the traffic seen by the cache. While it is true that caches will grow larger when it starts validating and storing DNSSEC results, it depends on the traffic seen and the amount of that traffic that goes to DNSSEC signed zones. There is no rule of thumb in this manner, but it is possible to give a customized estimate for a single cache based on the traffic model seen at the cache.
Longer resolutions time now that validators are building chains of authentication
True, however there is no solid data (yet) on the exact impact. The impact would depend on the traffic, validator processing speed, and configuration. All of which vary depending on the organization and network. The response time will be worst when the validating cache first starts up, however, caching of DNSKEY and DS RRs will speed up validation time. Administrators may wish to consider storing the public keys of known popular sites (e.g., gTLD's frequently visited) to speed validation on startup, etc.
DNSSEC responses are too large, and will truncate messages or require TCP
The DNSSEC specification requires Extended DNS (EDNS) as part of the protocol. EDNS allows for larger UDP packet sizes and allows clients and servers to indicate the preferred UDP size in a query/response transaction. Previous studies on DNSSEC have show that a UDP packet size of 1500 bytes is sufficient for most DNSSEC responses, but it is up to the individual client or server to advertise a smaller or larger size.
Key Distribution Issues
DNSSEC Needs a way to securely distribute keys
There are numerous ways to distribute keys – similar to the way root X.509 certificates and key material used in other security protocols (e.g. SSH) are distributed. There are also ongoing work in forming trust anchor repositories to aid administrators in locating, choosing, installing and updating DNSSEC trust anchors.
Isn't there more potential points of service failure as trivial zone configuration errors or an expired key
True, but there are tools and specifications available to ease automation of these operations. After the initial setup, management becomes easier. This is just like every other protocol security feature that may add authentication and integrity protection, but at the cost of operational fragility.
Clients will not be able to establish trust for all the zones that do not have a signed parent.
Clients only need to obtain the keys from the zones they desire DNSSEC signed responses. There are specifications and tools available to minimize this maintenance overhead (See RFC 5011 and 'trustman' from dnssec-tools.org). As more TLD's (and possibly the root zone) are signed, this is expected to become less of a problem as a single TLD key can be used as the anchor for all the delegations under that TLD. Likewise the root zone key can be used as the trust anchor for the entire DNS.
Zone Enumeration
Not until the zone enumeration issue is completely resolved, verified, and tested
There are several options available to minimize this risk. The NSEC3 option has been fully specified and is implemented in major DNS authoritative server releases (BIND, NSD). NSEC3 has been tested in a series of workshops and has been examined by security experts. There are also operational measures that can be used to protect sensitive hosts and only have those hosts that would not be harmed by exposure (such as public servers which already are exposed on the public net). A March IEEE Network magazine article examines the different approaches: Minimizing Information Leakage in the DNS.
Hardware/Software and Infrastructure Issues
There is no products that do DNSSEC.
Several options exist that do support DNSSEC or have publicly stated DNSSEC will be present in future releases. See the list of current software for the latest review of DNSSEC enabled products and the ICANN Survey of Available Tools.
Applications don't support it and will not work with DNSSEC
Clients must request DNSSEC records in a query. Otherwise DNSSEC processing is not signaled (default operation) and the client receives a standard DNS reply. DNSSEC is backwards compatible with standard DNS in that clients must signal that they wish DNSSEC enabled responses, otherwise standard DNS protocol is used.
There is no support for DNSSEC in hardware/firmware
Not true – multiple HSM vendors have API or are developing API’s to use with their products. DNSSEC does not require specialized hardware except for extreme cases where multiple changes are made to the zone every minute (e.g., .com/.net). Otherwise, commodity hardware and software can be used. The DNSSEC-Deployment Initiative Tracker provides a list of available DNSSEC hardware options.
I use dynamic load balancing system and it can't do DNSSEC.
The issue of DNSSEC's impact on load balancing systems has not be fully studied. The impact on a particular system depends on how that system forms DNS responses. It may be possible to implement DNSSEC on some systems with minimal impact to the current system's operation.
Yes, when it's released as part of Windows Server
Microsoft has publicly stated DNSSEC support will appear in servers in future releases. See a Microsoft presentation on DNSSEC deployment plans for more details.
I'll do it when the root servers support it.
I'll do it when my parent is signed.An organization does not need to wait for their delegating parent to be signed before deploying on their own zone. Deployment within a domain can be done in parallel because each zone must develop their own internal DNSSEC procedures before developing a plan with their delegating parent on establishing secure delegations.
Until a secure delegation can be established, a zone can exist as an island of trust. The zone may take steps to publish their public keys as a trust anchor if they wish or have the ability to publish their key through a trusted manner.
Last updated 9/12/2008. Questions
or comments should be sent to dnssec-proj@antd.nist.gov