Note: this FAQ assumes familiarity with core DNS concepts, such as resource record (RRs).
DNSSEC is a set of extensions to the DNS that permits authentication and data integrity checking of DNS data.
DNSSEC doesn't modify the existing DNS resource records (RRs) associated with a particular configuration; it simply adds additional records to the DNS data which permit the validation of data in the DNS using strong cryptography.
The DNS in its present state is subject to a number of threats. The DNS is particularly vulnerable to spoofing attacks in which a malicious host intercepts DNS queries and then returns incorrect replies. Such an attack could be used to redirect unsuspecting users to a malicious site, e.g. a phishing website or a website which infects vulnerable clients with malware.
To date, exploits which realise these threats have been few; however increasingly sophisticated techniques are being used to attack the DNS, and it's likely that DNS exploits will increase in number and severity in much the way as viruses and worms have.
A comprehensive DNS threat analysis and ways in which DNSSEC addresses these threats is available as RFC 3833:
http://www.ietf.org/rfc/rfc3833.txt
As well as addressing threats, DNSSEC also presents opportunities. For example, DNSSEC makes it possible to host DNS data on untrusted hosts. This could permit DNS data to be distributed among orders of magnitude more hosts and thus considerably reduce the vulnerability of the DNS to DDoS attacks.
DNSSEC also makes it safe to put security-related data in the DNS, e.g. IPsec certificates and SSH keys.
DNSSECbis an informal name used to refer to the version of DNSSEC defined by RFCs 4033, 4034 and 4035 that were published in March 2005. The suffix `bis' denotes that it is a newer version of the original DNSSEC defined by RFC 2535 that was published in 1999.
(Adding the suffix `bis' to a base standard name to indicate a newer version is a practice borrowed from the ITU. `bis' is a French musical notation meaning `repeated'.)
The most significant change is the introduction of the DS (`Designated Signer') resource record. The DS RR simplifies the interaction that must occur between the maintainers of a parent zone and child zone when both zones have been secured with DNSSEC. The complexity of this interaction in the original version of DNSSEC made it impractical for deployment.
DNSSECbis also requires the use of EDNS0 (Extension Mechanisms for DNS), which permits servers to send replies with more than 512 octets without truncation. DNSSECbis requires that all DNSSEC-capable name servers and resolvers support DNS packets with payloads of at least 1220 octets, although 4000 octets is recommended.
Also the Secure Entry Point (SEP) flag was added, permitting the existence of `islands of trust', which facilitates the incremental deployment DNSSEC.
Note that the other three DNSSEC resource records types have been replaced with new ones in order to avoid any confusion between the two versions:
| Record Type | RFC 2535 | RFC 4033-4035 |
|---|---|---|
| DNS Public Key | KEY | DNSKEY |
| Resource Record Signature | SIG | RRSIG |
| Next Secure | NXT | NSEC |
Which DNS servers support DNSSEC?
The following name servers support DNSSEC:
ISC BIND http://www.isc.org/sw/bind/ or http://www.nlnetlabs.nl/nsd/
(Note: nsd requires tools from BIND to generate keys and sign zones.)
Nominum Authoritative Name Server (ANS)
http://www.nominum.com/products.php?id=2
As of this writing (June 2005) there are only a handful of DNSSEC-enabled zones (including this testbed).
The DNSSEC-enabled zones in the public DNS of which we are aware:
(There are no doubt others; please let us know of any that don't appear on this list.)
The use of DNSSEC by these zones may be observed by using `dig':
dig +dnssec +multi <zone> dnskey
e.g.:
dig +dnssec +multi uk-dnssec.nic.uk dnskey
(Note: dig version 9.3.0 or later must be used.)
There are other experimental DNSSEC-enabled zones that require the user to specify an alternate set of name servers, e.g.:
dig @65.201.175.33 +dnssec +multi net. dnskey
Probably not. DNSSEC will do little to remedy the current type phishing attacks because they don't rely on spoofing DNS data.
Phishers nearly always use valid domain names or IP addresses. Frequently they use domain names they have registered themselves, typically under a false or assumed identity. The selected domain names may appear similar to that of the business or person that they are attempting to imitate. For example, a phisher might register `paypalsecurity.com' in order to imitate PayPal's web site. Using DNSSEC would only show that the DNS results returned for `www.paypalsecurity.com' had not been tampered with, rather than that the domain name was being used in a misleading way.
It's been demonstrated that insecure public networks, such as WiFi or university networks, could be used for a type phishing that uses DNS spoofing; however this type of attack would generally yield many magnitudes fewer victims than the current ones, so would only make sense with particularly high-value targets or for targeting specific users.
Yes. Setting the Checking Disabled (CD) bit in a query will cause a caching resolver to return results without validating the corresponding DNSSEC data. The CD bit may even be set at the same time as the DNSSEC OK (DO) bit, so that DNSSEC data will still be returned.
To set the CD flag using `dig', use the `+cdflag' option. To set the DO bit, use the `+dnssec' option.
(Note: dig version 9.3.0 or later must be used.)
No. DNSSECbis requires both the DNS client and server to use EDNS0 DNSSEC responses may exceed 512 octets without truncation; specifically, DNSSECbis specifies that they support message sizes of least 1220 octets (bytes), although 4000 octets is recommended.
Historically DNS messages have been limited to a UDP payload size of 512 octets. Responses requiring more octets resulted a truncated response with the TC (Truncation) bit set, indicating that the client should retry the query using TCP. RFC 2671, Extension Mechanisms for DNS (EDNS0), added a provision for DNS clients and servers to negotiate a larger UDP payload size, typically 2 KB or 4 KB.
The key-signing key, or KSK, and the zone-signing key, or ZSK, are both DNSKEY resource records (RRs) in a DNSSEC secured zone. The KSK is used to sign only one record in the zone: the ZSK. The ZSK is then used to sign all the other record in the zone.
The reasoning behind this split is that the ZSK can be `rolled over', or replaced at frequent intervals, e.g. daily, via an automated procedure while the KSK can be changed much less frequently, e.g. annually. This permits the private key of the KSK to be stored offline where is less vulnerable to compromise, while the private key of the ZSK may be stored where it is readily accessible by automated routines. This also permits the KSK to use a larger key size (e.g. 2048 bits as opposed to 1024 bits) without resulting performance penalties.
The KSK is distinguished from the zone-signing key by the secure entry point (SEP) flag in the DNSKEY RR. The value of the flags section of the DNSKEY RR is displayed as 256 for a ZSK and as 257 for a KSK. (The SEP bit is the low-order bit. Bit 7 means that the DNSKEY is a Zone key as opposed to a TSIG or SIG(0) key.)
This depends on a number of factors:
1. Which key (KSK or ZSK),
2. How frequently key rollover will be performed on that key, and
3. What the threat model is.
If your organisation is an attractive target, you will want to use a commensurately larger key size as attackers are more likely to bring to bear more resources attempt to recover your signing key. Examples of organisations that may wish to use larger key sizes are banks, military and high-volume e-commerce.
At the moment the general thinking is that for lower-security applications, KSKs of 1024 bits and ZSKs of 512 bits are suitable and that for higher security applications KSKs of 2048 bits and ZSK of 1024 bits are suitable, assuming a monthly ZSK rollover and annual KSK rollover. There is ongoing work to come up with more precise recommendations.
In any event, the use of even 512-bit KSKs will result in a significant theoretical improvement in DNS security over the use of no DNSSEC whatsoever.
DNSSEC RRs are large - significantly larger than the basic DNS RRs (A, PTR, NS, MX and SOA). An A RR is <domain name length> + 14 octets; however a typical DNSKEY or RRSIG RR is larger than the key size, which will likely typically be 1024 octets. Every RR in a DNSSEC-secured zone has a corresponding RRSIG RR, except for RRSIG RRs themselves and `glue' A RRs. It's possible (but probably not desirable) to have multiple RRSIG RRs for each RR.
Accordingly, a signed zone uses more disk space on name servers, and more memory on both name servers and caching resolvers, than an unsigned one. The precise increase depends on a number of variables, particularly key size and the types of RRs in the zone, but the following approximate increases may be expected:
| Location | 512-bit ZSK | 1024-bit ZSK | 2048-bit ZSK |
|---|---|---|---|
| Disk | 6.1 x | 7.7 x | 11.0 x |
| RAM | 2.5 | 2.5 | 3.7 |
The size of DNSSEC responses is also significantly larger.
Finally, DNSSEC-enabled caching resolvers also have to perform CPU-intensive cryptographic validation operations. They only have to do this for signed zones for which they have a trust anchor, and should begin consume additional CPU only as a function of DNSSEC deployment (although signing .com could result in a quantum jump). Note that someone could deliberately or inadvertently cause a degradation of service by sending large number of queries for uncached RRs, for example, traversing the NSEC RR chain for a large TLD.
There are a number of issues that complicate the deployment of DNSSEC:
A trust anchor is the DNSKEY RR or, less frequently, the DS RR hash, which is at the top of a region of the DNS which has been secured using DNSSEC. Ideally this would be the Key Signing Key (KSK) of the root zone; however the `signing of the root' is a politically charged issue that is unlikely to be resolved any time soon.
Without a signed root, each TLD than enables DNSSEC will have to arrange for the distribution of their trust anchor to security-enabled recursive resolvers worldwide. There are several proposals for doing this with minimal operator involvement, including a scheme proposed by Paul Vixie called DNSSEC Lookaside Validation (DLV). VeriSign have a pilot project based on DLV:
http://www.dlv.verisignlabs.com/
Another unsolved operational problem in the provision of a priming method for trust anchors. This is an issue even if there is only a single trust anchor to prime. Consider the hypothetical case where a new DNSSEC-enabled computer sits on the shelf for three years before being installed. If a trust anchor has been embedded in the resolver, it will almost certainly have been expired, or `rolled over', some time before. The computer has to have some way of obtaining the new trust anchor in a secure way that doesn't depend on the old one, which might possibly have been compromised in the interim. Some proposals for doing this is detailed in:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-trustupdate-threshold-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-trustupdate-timers-00.txt
TLDs and other registries generally have not yet developed tools for managing DNSSEC. Registries wishing to deploy DNSSEC will require tools to sign the zones that they manage and roll over the zone signing keys (ZSK) and key signing keys (KSKs) on a regular or emergency basis. Also, existing interfaces must be modified to accept DS RRs (or possibly DNSKEY RRs) from registrants and/or registrars/agents.
Even with these tools in place, policies and procedures will have to be developed to make the management of DNSSEC possible.
The recent effort to develop DNSSEC has focussed nearly exclusively of the infrastructure side. Very little attention to date has been given to what the `user experience' will be of DNSSEC. Even if ISPs deploy DNSSEC-enabled resolvers and users subsequently use them, applications won't distinguish between ordinary DNS failures and DNSSEC validation failures. In the future, applications or operating system APIs (e.g. the `gethostbyname' network library call) may be modified to report when DNS data fails to validate.
There is debate as to whether this distinction should ever be made. One concern is that applications might be modified to permit users to `click through' DNSSEC validation error messages and use the invalid data. This is comparable to the problem today where users can click through warning messages to use web sites that have been secured with expired or invalid X.509 certificates.
One of the design requirements for DNSSEC was to provide authenticated denial-of-existence. In other words, if a domain name doesn't exist in a DNSSEC-secured zone, a signed reply should be sent in response to queries for that name. Otherwise, even if a zone is secured by DNSSEC, DNS replies claiming that the name doesn't exist could be trivially forged.
One way this might have been implemented would have been for security-enabled servers to sign each NXDOMAIN (`no such domain') reply. However this had two significant drawbacks: the private keys would have to stored on the DNS servers, where they would be particularly vulnerable, and security-enabled servers would be more susceptible to denial-of-service attacks, as there is a substantial asymmetry between the work required by the server to send an NXDOMAIN response vs. the work required by the client to generate queries for non-existent names.
The designers of the DNSSEC protocol developed an elegant solution to these problems. Instead of signing NXDOMAIN responses in real-time, a security-enabled server could use a set of resource records (RRs) (originally called NXT, now called NSEC) that would identify the gaps between domain names that existed in a zone. These RRs could be generated and signed beforehand. Whenever a query was sent for a domain that didn't exist in the zone, the server could return a response that said in effect, "this domain name doesn't exist, and to prove it, here are the two names that do exist in the zone between which this one would have existed". This is the electronic equivalent of turning one's pockets inside out to demonstrate that they don't contain a particular object.
Unfortunately NSEC RRs have one property that is considered undesirable by many DNS operators: the set of domain names in a zone can be reconstructed by someone sending repeated queries for names in that zone. This is particularly nettlesome to some TLD managers concerned that this information could be used for fraudulent activity. Nominet is one such TLD manager, and is currently spearheading an initiative to modify the DNSSEC protocol to use a modified type of NSEC RR that doesn't reveal actual names in the zone.
DNSSEC introduces significant new complexity for DNS operators. DNS configurations are much more complex and introduce many new opportunities to cause the DNS for a domain name to fail. Also, trouble-shooting DNS failures entails the investigation of many more considerations.
Historically the most common types of DNS misconfigurations have been things like disagreements between the parent zone and child zone as to what the authoritative name servers are for the child zone. Now many other things can cause the DNS to fail: an incorrect DS RR in the parent zone; non-existent, incorrect, corrupt and/or expired RRSIG RRs in the child or parent zone, failure of resolvers to observe the rollover of a trust anchor, and so on. Unlike simple parent/child disagreements, these are more difficult to detect by simple inspection.
Perhaps the most significant barrier to DNSSEC deployment is the public's lack of a perceived threat to the DNS.
There was one major incident of DNS spoofing in 1997 in which a Washington state computer consultant named Eugene Kashpureff used cache poisoning to redirect traffic from www.internic.net (InterNIC was the organisation which managed the .com, .org and .net TLDs at the time) to his website at www.alternic.net. However, the success of this hack owed more to weaknesses in the way BIND handled untrusted information; this weakness has long since been corrected.
Subsequently there has been no other `reference incident' to bring the weaknesses of the DNS protocol to public attention, and even DNS experts can mostly only speak of potential threats. Consequently there is very little demand for the enhanced security afforded by DNSSEC. This could change rapidly if there is a major incident, or an epidemic of minor incidents (as has been the case with spam).
Because the current version of DNSSEC has only recently been published, there is little written about it that is aimed at the non-specialist reader. Cricket Liu's excellent book DNS and BIND, 4th edition covers only the old version of DNSSEC defined by RFC 2535 and not the current version defined by RFCs 4033, 4034 and 4035.
For More information about DNSSEC, see the following resources:
* RFC 4033 - DNS Security Introduction and Requirements
* RFC 4034 - Resource Records for the DNS Security Extensions
* RFC 4035 - Protocol Modifications for the DNS Security Extensions
These RFCs define the DNSSEC protocol. They are not light reading.
* RIPE DISI DNSSEC HOWTO - http://www.ripe.net/projects/disi/dnssec_howto/
This is an excellent hands-on DNSSEC tutorial written by one of the co-chairs of the IETF dnsext (DNS extensions) working group.
* Jacco Tunnissen's dnssec.net website - http://www.dnsssec.net/
This is an extensive collection of links to all sorts of DNSSEC resources, including papers, articles, presentations, projects, and tools.
The DNSSEC Deployment Initiative is a working group of experts active in promoting the development deployment of DNSSEC that is supported by the US Department of Homeland Security:
They've published a `roadmap' that examines in detail the steps required to reach the goal of enabling all DNS traffic on the Internet to be DNSSEC compliant:
http://www.dnssec-deployment.org/Roadmap rel 1.pdf
At the moment the DNSSEC testbed is static: with the exception of periodic zone re-signing and key rollover, the testbed data does not change. We are developing a version of the testbed on which Nominet registrars (tag holders) will be able to `register' names in a sample DNSSEC-secured zone. We hope this will help registrars to familiarise themselves with DNSSEC before it is deployed.
Nominet is also actively involved in creating extensions to the DNSSEC protocol that will make DNSSEC-secured zones resistant to enumeration. This work is detailed in the following Internet Draft:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-01.txt
We plan to have a working implementation of these extensions sometime in Q3 2005. When we do, we will make examples of zones secured with these extensions available via this testbed.
We've found that the local Internet community in the UK is more concerned about the potential for the loss of data privacy made possible by DNSSEC than any gain in security it could provide. As mentioned in the previous answer, we are actively involved in creating extensions to the DNSSEC protocol that will make DNSSEC-secured zones resistant to enumeration. These will have to become an IETF standards-track specification before deployment could be considered, and process to become a standard is expected to take several years.
gTLD registries such as VeriSign Registry (.com, .net), Public Interest Registry (PIR) (.org) and Afilias (.info) must make the contents of their zone files publicly available under the terms of their agreement with ICANN. Consequently they have little incentive to prevent enumeration of data in their zone files. ccTLDs don't have any such agreement with ICANN, so they can afford to be more protective of their data. Some ccTLDs have committed to deploying DNSSEC anyway, notably Sweden (.se) and the Netherlands (.nl); others, such as Germany (.de), have clearly stated that the privacy exposure is unacceptable.