Domain Name Security Extensions (DNSSEC) is an upgrade to the security of the Internet. Conforming to international specifications set by the Internet Engineering Task Force (IETF), it is designed to add security by protecting you against attacks such as cache poisoning. DNSSEC is one way to prevent pharming. All answers in DNSSEC are digitally signed. By checking the digital signature, you can verify if the information is identical to the information on the authoritative Domain Name System (DNS) server.
Digital signatures provide the mechanism for cryptographic authentication in DNSSEC. A digital signature proves that the message originated from a certain source and that the message has not been changed. Just as a written signature is inextricably attached to a written document, a digital signature is inextricably attached to digital information.
The DNS works on a concept of “implied trust”. When you click on a website link, your computer will take you to whatever first reply it receives, and does not check whether it is getting reliable information on where to go on the Internet. This insecure system is used not only by your local computer, but by all servers and by all Internet Service Providers (ISPs) on the Internet. This creates a giant security hole in the Internet which made it possible for attackers to do a “cache poisoning”. This would result in any of your customers who click on a web link to reach your website automatically being redirected to some other location where their information may be stolen, compromised or used for criminal and other malicious purposes. Adding DNSSEC to your domain name can help reduce the chances of traffic hijacking. When properly maintained, DNSSEC zones provide extra security by preventing man-in-the-middle attacks and hijacking of traffic.
DNSSEC adds a signature to each and every DNS query and response on the Internet. When you sign your domain name with DNSSEC, each piece of your domain name’s DNS information adds a digital signature. When your customer types in your website address, or clicks on a link, a security-aware DNS resolver will only trust answers that have this signature attached to it. If the signature does not match, the security-aware DNS resolver discards the response. Technically speaking, DNSSEC ensures that the answer you receive came from a trusted name server. All answers in DNSSEC are digitally signed. By checking the digital signature, a DNS resolver is able to check if the information is identical (correct and complete) to the information on the authoritative DNS server.
What if a query is made for records that do not exist? An unsecured DNS server returns the Start of zone of Authority (SOA) record of the enclosing zone, along with an error code indicating the specific error that occurred.
This provides the opportunity for a "replay attack," which repeats an earlier "non-existence" response. This can make actual hosts "disappear" as it spoofs an existing type as non-existent.
In order to provide authenticated denial of records that do not exist yet avoid the replay attack listed above a new record type is introduced: the NSEC (or the latest NSEC3) record. An NSEC record exists for each DNS name with any associated records. The NSEC record's data includes the name of the next DNS entity in the zone, as well as a list of the types of records present for the current name. When a DNS server responds to a query for which there are no matching records, the DNS server sends the "covering" NSEC record. All possible names are thus either present in the DNS or in a range covered by exactly one NSEC record.
The primary name server for a zone creates the RRSIG records for each set of records in the zone, as well as the NSEC records for each name. Software known as a "zone signer" signs the data for each zone.
The signer reads in all zone data, and organizes the data. All names are arranged in order and NSEC records are built for each name. All records are grouped into sets and RRSIG records are generated for each set. This information is placed in a file that is subsequently used by the zone primary name server to provide the authoritative information for the zone.
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 increase depends on a number of variables, particularly key size and the types of RRs in the zone. 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. 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.
A key pair contains two digital keys – a private key (held by the signer of the zone, which is usually the DNS Operator) and a public key (distributed to the public through the DNS). The zone is signed by using the private/public key pair. End users’ validators (or the validators at their ISPs) use the public part of the key pair to validate the digital signature created when the zone is signed.
A key rollover occurs whenever it is necessary to change the private key used to sign a zone or the public key used to validate a zone. This can occur for planned or unplanned reasons. Planned rollovers occur as an ordinary part of key management procedures, similar to changing a password on a regular basis. Unplanned rollovers occur whenever a key has been compromised or whenever a change of staff among those who have access to the private key.
This would also mean that a re-signing needs to be done and the new public key needs to be sent to the parent in the form of the Delegation Signer (DS) Record.
As with any other application of cryptography, the keys can become compromised over time. As computers get faster, cryptanalysis becomes more effective. The host possessing the key may be compromised so that the key can be freely obtained. Changing keys periodically can help prevent keys from being compromised. Furthermore, using larger public keys makes cryptanalysis more difficult. However, public keys should not be so large that verification becomes unwieldy (signing is not a part of normal server operation, so it is less critical).
DNSSEC uses several mathematical formulas (cryptography) to “sign” a zone. They are subject to cryptanalysis. It is therefore possible for an attacker to learn the private key in a key pair even though that key has never been disclosed, either through “brute force” or other types of attacks. Every attack requires time to complete. Periodically changing the key decreases the length of time an attacker has to attempt the compromise.
Under ordinary circumstances key rollovers are not visible to end-users. The transition from one key to another is handled automatically by the DNS and validating resolvers, as long as the actual zone signer properly manages the key pairs and enters the changing keys in to the DNS as needed.
Within the context of DNS, security only refers to authentication, not confidentiality. DNSSEC extends DNS so that resolvers can receive provably correct information. DNS itself (the protocol, not necessarily all implementations) has no way of hiding data - a query can originate from any host, and any host will receive the same answer to the same query. Access control is not part of DNS, and it is not part of DNSSEC. Information designed for private viewing should not be stored in DNS.
- Network Security: Domain Name System (DNS) Security, Brian Wellington.
- Nominet DNSSEC Test Bed FAQ:
- Wikipedia: DNSSEC
- A Fundamental Look at DNSSEC, Deployment, and DNS Security Extensions, Geoff Huston.
- Wikipedia: Replay Attack
- Names Beyond: DNSSEC-FAQ
- MYNIC R&D portal on DNSSEC
- .ORG: DNS Security Questions