What is DNSSEC?
DNS Security (DNSSEC) is a method for supplying cryptographic verification information along with DNS messages. Public Key Cryptography is used in conjunction with digital signatures to provide a means for a requester of domain information to authenticate the source of the data. This ensures that it can be traced back to a trusted source, either directly, or via a chain of trust linking the source of the information to the top of the DNS hierarchy.
Top
What are digital signatures?
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.[NETSEC]
Top
Why do we need DNSSEC?
Information crucial to the operation of the Internet is stored in a distributed database. Because of the distributed nature, changes to the database do not propagate through all of the DNS servers on the Internet instantly. This complicates the process of verifying any single piece of information. Since many different organizations control the Internet, it is not considered a trusted medium.
There is no guarantee, for example, that the data received by a name server is authoritative, or that a name server is not maliciously providing false information.
DNS Security prevents clients from trusting false information. All data must be authenticated before it can be trusted. To prove the authenticity of data, an authoritative source must create and digitally sign the data.
Additionally, there is no guarantee that the client and server performing a DNS transaction are the entities they claim to be. DNS transaction security (TSIG) can provide this level of trust.[NETSEC]
Top
How does DNSSEC work?
DNSSEC adds two new record types for authentication into DNS.
There is the KEY record and the SIG record. The KEY record stores the public key for a host or administrative zone. The SIG record stores a digital signature associated with each set of records.
In a signed zone each record set includes a SIG record.
The SIG record contains the signature of the set as generated by the above zone KEY.
A DNSSEC aware resolver can determine whether or not a zone is signed, and if the resolver sees an unsigned record set when it expects a signed one it can identify that there is an error.
Top
What is authenticated denial and why should I care?
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.
A secured server could additionally provide a SIG SOA record. Although this seems sufficient, it provides the opportunity for a "replay attack," which repeats an earlier "non-existence" response. This can make actual hosts "disappear."
In order to to provide authenticated denial of records that do not exist yet avoid the replay attack listed above a new record type is introduced: the NXT (next) record. An NXT record exists for each DNS name with any associated records. The NXT 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" NXT record. All possible names are thus either present in the DNS or in a range covered by exactly one NXT record.
Top
What does it mean to "sign a zone?"
The primary name server for a zone creates the SIG records for each set of records in the zone, as well as the NXT 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 NXT records are built for each name. All records are grouped into sets and SIG 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.[NETSEC]
Top
What is transaction security and why should I care?
An end system’s non-DNSSEC aware client ("resolver") is usually a simple library. Each time this resolver needs DNS information, it builds a query, sends it, and reads the response. This requires little processing and no caching. While this is a reasonable design, it is very inefficient for DNSSEC. Since the resolver does not cache records, the resolver must obtain the entire chain of KEY and SIG records for every query. One solution is to add caching to this type of resolver, but this adds complexity.
In most cases, this resolver communicates with only a small number of DNS servers on the same local network. If the resolver can trust the local server, then it can offload all DNSSEC processing to the server, leaving the problem of securing communication to the server. Since there are only two participants in the communication between resolver and local server, they can protect the communication using secret key cryptography. Secret key cryptography has the added advantage that operations require less CPU usage than public key cryptography, so the stub resolver does not need to be especially fast.
The resolver and server share a secret key. The key is determined and transmitted via any secure method. Once the server and resolver exchange keys, every message from the resolver can include a request signature, and every message from the server can contain a transaction signature. These signatures are generated with the shared key and authenticated by the receiver. The signature is added to the DNS message in a TSIG record, which is included at the end of the additional data section.
Top
What about DNS as a Public Key Infrastructure?
DNS manages the keys used by DNSSEC in KEY records. KEY records can store more than just DNS keys, though. Any application or protocol can store public keys in DNS. Each KEY is associated with a category–it is either
a Zone key (see 1.4 - "How does DNSSEC work?")
a Host/End Entity key (associated with a host)
or a User key (associated with a user: DNS can store user names).
Additionally, each KEY refers to a protocol that it is used with, such as DNSSEC, email, IP Security (IPSEC), etc.
Given the ubiquity of DNS, it offers an ideal mechanism for providing services designed to assist authentication to other protocols. Consider a program providing secure logins. Host A connects to host B, and the message includes a digital signature. For host B to verify the message, it must know A’s public key. If DNS stores the public key, host B can easily retrieve A’s key and verify it as such. The DNS "chain of trust" provides certification as well, since walking the chain of trust is similar to the verification process for a certificate.[NETSEC]
Top
What are the size concerns of these DNSSEC related records and signed zones?
Compared to other DNS records, public keys and signatures are fairly large. This property makes both messages and zones larger. For example, the size of an A record is 4 bytes plus the record header, but a SIG generated by a 640 bit RSA key will be over 100 bytes. Similarly, where an unsigned zone stored by a name server may have only an A record for each name, the signed zone would have an A record, an NXT record, and a SIG record for each zone.[NETSEC]
Top
Do I have to worry about the keys being compromised?
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).[NETSEC]
Top
What about confidentiality vs. authentication?
Within the context of DNS, security only refers to authentication, not confidentiality. DNS Security 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 DNS Security. Information designed for private viewing should not be stored in DNS.
Top
References
[NETSEC] Network Security: Domain Name System (DNS) Security, Brian Wellington. [http://www.pgp.com/research/nailabs/network-security/an-introduction.asp]
