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:
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|
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 ( AwEAAa/KVVdwmvrpdIP650gGoFqbx/W76h+APAJyxfpx YIuT3AJqXy+6reUNzaTC89O6UBmFMPKFoLP9iavAcfgc QnmI50XoCWRCnCF30CIIaIOMJ5ze4s8QIT0MPHDHM5l5 vBo87Bu6CUNn3FrmiC0LJd9fqvwvI3P4Z4GQ+xb06w3a h3NOxUaqhizoDcqsFERY8QGYmiFb33cOIseYJNkufomf PLkVeTC2R6CU6zNdFXbeNOqv7pTW1/jftlsH5L6mJEdk 71VHg4+Y2q/VuR7+s/Ju/VpVELS5ggcyjK2O0Ei5kPKg m9zpOjSw4wJWhbp7PVTxX3PnvyxuRlOJs2ksdcE= ) ; key id = 12319
This is a summary of RFC 4034, chapter 2.
- 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
- Protocol: The only currently defined value is 3.
- Algorithm: The type of key. In this case RSA/SHA-1
- 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.
- The key tag
- Algorithm: The type of key. RSA/SHA-1 in this case
- Digest type: the method used to calculate the digest. In this case SHA-1
- 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