DNSSEC, short for DNS security, provides a security extension to the all important DNS system. A nice intro can be found on wikipedia. This is a part of a series on DNSSEC:

  1. The RRSIG record
  2. The NSEC and NSEC3 record
  3. The DNSKEY and DS record
  4. Implementation

To verify the digital signatures inside the RRSIG records, the client needs to have access to the corresponding public key. What better mechanism than DNS itself could be used to convey this information to the clients? Public keys are stored in DNSKEY records inside the zone. To facilitate key rollovers, new keys are added ahead of time, while old keys remain in the zone until all entries have expired in the caches.Obviously, the DNSKEY record is protected by an RRSIG, but this isn’t enough: The correctness of the DNSKEY record can be verified by the RRSIG, which can be verified by the DNSKEY! An additional mechanism to verify the DNSKEY is thus required. This is where the DS record comes in. It stores a summary of the DNSKEY in the parent zone, protected by the parents DNSKEY. This goes on in a tree-like structure, up to the root DNS zone. This root DNSKEY needs to be protected by some other means.

The following table shows the chain of protection. Every record is protected by the next row. The last row needs to be protected out-of-band. Note that the RRSIG and DNSKEY are in the same zone, while the DS is one level up.

Owner name Record type Zone
www.example.net. A example.net.
www.example.net. RRSIG example.net.
example.net. DNSKEY example.net.
example.net. DS net.
example.net. RRSIG net.
net. DNSKEY net.
net. DS .
net. RRSIG .


As said before, this whole chain depends on the root zone being signed. At this moment, this is not the case (current plans are july 2010). So instead of a single “Secure Entry Point” (the root), there are many: one for every orphan zone (in DNSSEC-sense). To provide a temporary workaround, DLV (DNSSEC Look-aside Validation) has been invented. This is a database containing the DS records of a lot of DNSSEC-zones, thereby providing a single Secure Entry Point (SEP) for the majority of the DNSSEC world.

The record data for DNSKEY

ripe.net.        3379 IN    DNSKEY 257 3 5 (
                            ) ; key id = 12319

This is a summary of RFC 4034, chapter 2.

  1. The flags: bit 7 (256) indicated this is a ZONE-key (the kind of keys used for DNSSEC). Bit 15 (1) indicates this is a Secure Entry Point
  2. Protocol: The only currently defined value is 3.
  3. Algorithm: The type of key. In this case RSA/SHA-1
  4. The key itself

The record data for DS

gov.br.            86400 IN DS 8401 5 1 (
                            5248DB0EAE4E829924F19D33B005FBC8C4606058 )

This is a summary of RFC 4034, chapter 5.

  1. The key tag
  2. Algorithm: The type of key. RSA/SHA-1 in this case
  3. Digest type: the method used to calculate the digest. In this case SHA-1
  4. The digest itself

Since the DS record is a summary of the corresponding DNSKEY record, you can generate a DS from the DNSKEY with the command dnssec-dsfromkey.