• Choose a category
• All
• Classic-Fiction

DNSSEC

DNSSEC is a set of DNS extensions that authenticate the origin of zone data and verify its integrity by using public key cryptography. That is, the extensions permit DNS clients to ask the questions, “Did this DNS data really come from the zone’s owner?” and “Is this really the data sent by that owner?”

DNSSEC provides three distinct services: key distribution by means of KEY resource records stored in the zone files, origin verification for servers and data, and verification of the integrity of zone data. DNSSEC relies upon a cascading chain of trust: the root servers provide validation information for the top-level domains, the top-level domains provide validation information for the second-level domains, and so on.

Public key cryptosystems use two keys: one to encrypt (sign) and a different one to decrypt (verify). Publishers sign their data with a secret “private” key. Anyone can verify the validity of a signature with a matching “public” key that is widely distributed. If a public key correctly decrypts a zone file, then the zone must have been encrypted with the corresponding private key. The trick is to make sure that the public keys you use for verification are authentic. Public key systems allow one entity to sign the public key of another, thus vouching for the legitimacy of the key; hence the term “chain of trust.”

The data in a DNS zone is too voluminous to be encrypted with public key cryptography—the encryption would be too slow. Instead, since the data is not secret, a secure hash (e.g., an MD5 checksum) is run on the data and the results of the hash are signed (encrypted) by the zone’s private key. The results of the hash are like a fingerprint of the data, and the signed fingerprint is called a digital signature.

Digital signatures are usually appended to the data they authenticate. To verify the signature, you decrypt it with the public key of the signer, run the data through the same secure hash algorithm, and compare the computed hash value with the decrypted hash value. If they match, you have authenticated the signer and verified the integrity of the data.

In the DNSSEC system, each zone has its own public and private keys. The private key signs each RRset (that is, each set of records of the same type for the same host). The public key verifies the signatures and is included in the zone’s data in the form of a KEY resource record.

Parent zones sign their child zones’ public keys. named verifies the authenticity of a child zone’s KEY record by checking it against the parent zone’s signature. To verify the authenticity of the parent zone’s key, named can check the parent’s parent, and so on back to the root. The public key for the root zone is included in the root hints file.

Several steps are required to create and use signed zones. First, you generate a key pair for the zone. For example, in BIND 9,

# dnssec-keygen -a DSA -b 768 -n ZONE mydomain.com.

or in BIND 8,

# dnskeygen -D768 -z -n mydomain.com.

Table 16.11 shows the meanings of the arguments to these commands.

Table 16.11 Decoding guide for dnssec-keygen and dnskeygen arguments

dnssec-keygen and dnskeygen return the following output:

alg = 003

key identifier = 12345

flags = 16641

They also create files containing the public and private keys:

Kmydomain.com.+003+12345.key # public

Kmydomain.com.+003+12345.private # private key

The public key is typically $INCLUDEd into the zone file. It can go anywhere after the SOA record, but is usually the next record after SOA.

DNSSEC requires a chain of trust, so a zone’s public key must be signed by its parent to be verifiably valid. BIND 8 had no mechanism to get a parent zone to sign a child zone’s key other than out-of-band cooperation among administrators. BIND 9 provides a program called dnssec-makekeyset to help with this process.

dnssec-makekeyset bundles the keys you want signed (there may be more than just the zone key), a TTL for the resulting key set, and a signature