What is DNSSEC?
The original design of the DNS was almost completely focused on data availability and did not include a security component. Fundamentally, DNSSEC solves two crucial problems related to the DNS:
Adds a data integrity check to the DNS; and
Adds the capability to authenticate the trust chain of data provided by the DNS.
DNSSEC also provides a platform for future security technologies.
DNSSEC is a backward-compatible technology that extends the DNS by providing origin authentication of DNS data, data integrity and, where needed, authenticated denial of existence of domain name and resource records.
It is important to understand that DNSSEC does not solve every security problem related to the DNS. DNSSEC does not provide confidentiality of DNS responses or communications between DNS clients and servers. It also does not prevent attacks on DNS servers using other parts of the network stack—for instance, implementation of DNSSEC does not protect against Distributed Denial of Service (DDoS) attacks. As any organization may be targeted by malicious actors using a DDoS attack, it is advisable that their security plan, and that of their DNS provider, include a DDoS mitigation plan. Despite some of the drawbacks, DNSSEC ensures users are not hijacked en route to their intended destination and thereby builds trust and confidence to users conducting online activities.
What is the fTLD Domain Security Requirement for DNSSEC?
DNSSEC must be deployed at each zone and subsequent
sub-zones for domains that resolve in the DNS.
Registrars must communicate the DNSSEC requirement to their Registrants in their Registration Agreements and store Registrant’s DNSSEC records. Registrars must support DNSSEC and registrants must deploy DNSSEC for each domain and subdomain name that resolves in the DNS.
How Does DNSSEC Work?
DNSSEC uses public key cryptography to authenticate domain names and verify the integrity of traffic to and from those names. The internet relies on the ability of people and computers interacting at a distance. A customer may not have ever seen or met the principals of an internet business, but they still have to be able to exchange information with them. How does that customer know that the information sent from the business is legitimate and not an imposter?
In the real world there are many physical clues and cues that guide the application of trust to transactions, however most of these are simply not available on the internet.
One of the keys to building private and reliable communications between people, businesses and organizations on the internet is to use cryptography. Many types of cryptography are in use in the public internet, but DNSSEC uses a very specific type: public key cryptography.
DNSSEC allows a user to make a traditional query about an address and by using a combination of typical DNS queries and the addition of verifiable trust, ensure that the server answering the query is authoritative and the response to the query has not been tampered with during transmission. This is illustrated below for www.example.bank.
Public Key Cryptography
Public key cryptography is a secure, easy-to-deploy method for ensuring that messages and transactions can be changed into a form that can only be read by the intended recipient.
Each person, business or organization gets two “keys.” One, the “public key” is given to all possible recipients and made public. The other, the “private key,” is kept secret and in the hands of the sender. Messages encrypted with the “public” key can only be decrypted with the matching private key and messages encrypted with the “private” key can only be decrypted with the “public” key. When sending a message it is encrypted using the public key of the recipient. Given the only person who can decrypt the message is the person who has the matching private key, it doesn’t matter if another party intercepts the message. Even if someone could intercept or get a copy of the encrypted message, they could not decode as they would not have the matching private key.
Public key cryptography has wide use in technologies such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), Pretty Good Privacy (PGP) and Virtual Private Networks (VPNs) as a strategy for protecting messages on the internet.
Digital Signatures
One of the features of public key cryptography that is of special importance is digital signatures. Simply put, if a private key is used to generate a signature of a document or encrypt a message, the recipient can verify that it is legitimate by verifying the signature against the public key of the sender. As with protecting the confidentiality of messages, the digital signature relies on the essential property of the key pair; messages signed with the private key can only be verified using the matching public key and vice versa.
The signature that is created using the digital signing algorithm verifies the authenticity of that message. The digital signature guarantees that the sender of the message is who they say they are. Digital signatures have three important properties:
AUTHENTICATION—Digital signatures are regularly used to authenticate the true source of messages. When a private key is used to sign a message, a valid signature indicates that the message was sent by the holder of the private key, and this ensures sender authenticity.
INTEGRITY—In addition to being confident that the message came from who purported to send it, it is also important to ensure that the message has not been altered in any way during transmission. This is often referred to as “data integrity.” A digital signature can ensure that the message was received just as it was sent: if a message is digitally signed, any change in the message after it was signed would invalidate the signature.
NON-REPUDIATION—If a sender has signed some information, they cannot, at a later time, deny having signed it. Similarly, that someone has access to a public key of another does enable them to use that public key to forge a valid signature.
DNSSEC makes essential use of the first two of these properties of digital signatures. The fundamental feature that DNSSEC provides is to guarantee that the answer received as a result of a DNS query is exactly the answer that corresponds to the authoritative state of the DNS records related to that query.
DNSSEC Resource Records
DNSSEC is an extension to the DNS and it adds records to the DNS that can be used by DNS clients to validate the authenticity and integrity of an answer to a DNS query. Where a DNS server must indicate that it has no records with which to respond to a query, DNSSEC provides a way for this “negative answer” to be authenticated as well. To accomplish this DNSSEC adds a set of new DNS resource records:
DNSKEY
RRSIG
NSEC
DS
Every zone file that is secured by DNSSEC has a public and private key pair. The administrator of the zone is responsible for keeping the private key secret. However, in order to check the signature on the zone data, DNS clients must be able to get a copy of the matching public key. As a result, the public key is published in the DNS using DNSSEC’s DNSKEY resource record. Here is an example of a DNSKEY record:
example.bank. 86400 IN DNSKEY 256 3 8 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
Cbl+BBZH4b/0PY1kxkmvHjcZc8no
kfzj31GajIQKY+5CptLr3buXA10h
WqTkF7H6RfoRqXQeogmMHfpftf6z
Mv1LyBUgia7za6ZEzOJBOztyvhjL
742iU/TpPSEDhm2SNKLijfUppn1U
aNvv4w== )
The Time-to-Live (TTL) value is one day (86,400 seconds). TTL is a value that controls how long any name server may cache the information that it may acquire in a query. The Flags value is 256, indicating that this is a Zone Key. The protocol value is a constant number: 3. The field that follows is the identifier for the public key algorithm, and the value 8 indicates RSA/SHA-256. The RR value is simply the encoding of the public key that the DNS client will use to validate the signed zone.
A Resource Record Set is a collection of resource records in a DNS Zone file that have a common name, class and type. In practice this means there would be a resource record set associated with each part of a DNS query response. Another way to say this is that the RRSIG is the Zone Administrator’s private key applied to the part of the zone requested by the client: a digital signature for the Resource Record Set.
In a typical zone with SOA (Start of Authority), NS (Name Server), A, MX (Mail Exchanger) and DNSKEY (Domain Name System KEY) resource records there would be five separate Resource Record Sets, each with a separate RRSIG record. Here is an example of a RRSIG record:
host.example.bank. 86400 IN RRSIG A 8 3 86400 20030322173103
(20030220173103 2642 example.bank.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrL
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
The zone name is followed by the TTL value and the Class field. RRSIG indicates the resource record type. These three fields are followed by a “Type Covered” field which indicates that this is a signing of the A resource records in “host.example.bank.” The next field indicates the name of the algorithm used to sign the resource record set. The number “3” indicates that there are three labels in the original zone name (in this case, “host,” “example,” and “bank.”). The next field (86400) indicates the original TTL value for the covered A resource record set. Following that are date stamps indicating when the resource record set was signed and when the signature expires. The key tag is 2642 and the signer’s name is “example.bank.” The rest of the RR value is the digital signature of the resource record set.
The DNSKEY and the RRSIG can be used to check the authenticity and the integrity of a DNS response, but only when there is a response. There needs to be a way to check the authenticity and integrity of a response when the DNS server is unable to find a result for the DNS query. The DNS doesn’t have a built-in resource record for this, so one was invented called the NSEC record.
The NSEC record was created so that something is returned in the event the resource requested does not exist. When a client makes a DNS query and either the name does not exist, or if the resource record type requested does not exist, the NSEC record is returned as a negative answer: a digitally signed indication that the name or resource record was not found.
Effectively the NSEC record is a way for the DNS server to bridge the gap between names in a secured zone. The strings in a zone file are sorted and then NSEC records are put in place to cover the gaps between the strings in the zone. If the zone contained the names “here” and “there” then there would be a NSEC record for “here” and its value would be “there” indicating that there are no defined names in the list of possible names between “here” and “there” Here is an example of a NSEC record:
alfa.example.bank. 86400 IN NSEC host.example.bank.
( A MX RRSIG NSEC TYPE1234 )
As before, the first four fields specify the name, TTL, Class and resource record type (this time, NSEC). This record then indicates that the next name, in sorted order, after “alfa.example.bank” in the zone is “host.example.bank.” The codes “A” “MX” “RRSIG” “NSEC” and “TYPE1234” indicate that there are “A” “MX” “RRSIG” “NSEC” and “TYPE1234” resource records associated with the name
alfa.example.bank. One implication of this is that, by collecting the information from the NSEC records, the entire contents of the DNS zone can be enumerated.
To prove a zone file’s DNSKEY is truly authentic, the client first verifies that the parent’s copy is authentic. It does this by calculating the signature of the key inside the DS record using the parent’s public key. If it matches the RRSIG associated with the DS record, then the parent copy is authentic. Next, the parent copy is compared against the child’s copy—if they are the same, the parent has authenticated the child’s DNSKEY.
While there may be times when the parent zone’s public key is suspected of being compromised, the chain of trust means that the parent zone’s public key can be checked against the copy of the parent’s zone held by the parent of the parent. The same process can be used until the DNSSEC client encounters a “trusted” DNSKEY. The ideal “trusted” DNSKEY is that of the root zone—and the good news is that the root zone has been signed since June 2010.
Here is an example of a DS record for the zone example.bank:
dskey.example.bank. 86400 IN DS 60485 8 1 ( 2BB183AF5F22588179A53B0A
98631FAD1A292118 )
As always, the first four fields are the name, TTL, Class, and resource record type (this time, the DS record). 60485 is the key tag for the corresponding “dnskey.example.bank” DNSKEY resource record. The number “8” indicates the algorithm used by “dnskey.example.bank” to construct the DNSKEY resource record. The value “1” indicates the algorithm used to construct the digest and the remainder of the record is the digest of the DNSKEY in hexadecimal format.
In essence, DNSSEC simply adds additional data to the responses that allow the DNS client to authenticate the resource records returned by the server.
If the client requests the security information:
If the string and resource record type being queried exist, the authoritative name server simply adds the RRSIG to the response;
If the string or the resource record being queried is not in the zone, the authoritative name server instead returns the NSEC record and its accompanying RRSIG record to indicate the negative response.
The DNS client can always take the returned RRSIG data and calculate its own copy of the signature to see if they match. The DNSKEY is needed to do this and if the client has not validated the DNSKEY within some set time period, the client needs to also validate the DNSKEY using the DS record stored at the parent zone. Each parent zone public key must also be validated in turn. Once the chain of trust is built and the signatures match, the DNS response can be considered to be validated and authentic.
DNSSEC and an fTLD Domain
To meet this requirement the zone, its parent zone, that zone’s parent zone, the fTLD Domain and the root of the DNS all must be signed. To tell if a zone is signed, all you need to do is see if it has a DNSKEY record. If it does, the good news is that it supports DNSSEC.
Fortunately, the root and fTLD Domain are already signed and have DNSKEY records. Suppose we want to sign example.bank—what would we need to do next?
Every zone gets two pairs of keys: the Zone Signing Key (ZSK) and the Key Signing Key (ZSK). It is common to generate those keys first. Then, the essential steps are:
Sign the zone with your ZSK
Sign the ZSK with your KSK
Publish the fingerprint of the KSK in the DS record published in the parent zone (for example, when signing the zone for example.bank, the DS record would be published in the .bank zone)
Every time the zone changes (perhaps a new domain is added to the example.bank zone, or the key needs to be updated) the zone must be resigned and the publishing task must be completed again. The process used for replacing one key in a zone with another is called a key rollover.
Keys in the DNS have a limited lifetime for security reasons. However, for fTLD Domain customers it is important that the existing chain of trust is not broken when the key rollover takes place.
A key rollover takes place when the records generated with the newest private key are first introduced into the zone. The key pair is often generated well in advance and the public key may also have been made public well in advance. Both key-signing keys and zone-signing keys are routinely (usually on a scheduled basis) rolled over.
DNSSEC Deployment for Registrars and Registrants
The process of generating keys, signing zones, generating, uploading and publishing DS records and managing key rollover is complex.
Registrars must support DNSSEC and provide tools for registrants to help publish DS records. Registrants must also support DNSSEC and have the tools for generating keys, signing zones, generating, uploading and publishing DS records and managing key rollover.
In cases where the registrant outsources the management of their fTLD Domain zone, they must ensure that the third party is able to successfully generate keys, sign their zones, generate and upload the DS records and manage key rollovers. For organizations that choose to outsource the DNSSEC management activity, there are a variety of vendors with service offerings that will comply with the fTLD Domain DNSSEC requirement. Webhosting companies, registrars and DNS management services may have service offerings that can assist a registrant in complying with the DNSSEC requirement.
In cases where a registrant has decided to implement DNSSEC on their own servers, it is useful to have tools that will help key management, signing, publishing and rollover tasks. In addition to commercial
tools that are easily found using simple searches on the internet, there are two primary open source approaches available:
OpenDNSSEC project at http://www.opendnssec.org
DNSSEC-Tools project at http://www.dnssec-tools.org
