I just read this message by Mark Andrews on the BIND mailing list. It explains the possible issues with DNSSEC and over-protective firewalls, giving test-commands to verify your setup. This post is also interesting for regular DNS traffic, since a firewall doesn’t know the difference.
Posts tagged ‘dnssec’
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:
- The RRSIG record
- The NSEC and NSEC3 record
- The DNSKEY and DS record
- Implementation
Time to put things together and setup a simple DNSSEC secured zone using BIND. Instead of providing a walkthrough, I’m just going to refer to the DNSSEC HOWTO (local mirror of the PDF version) of NLnetLabs. It provides a very thorough explanation of the whole DNSSEC concept, including copy-paste examples to try out. Also, it goes more into practical details such as key rollover, the benefits of using two keys (a Zone Signing Key, or ZSK, and a Key Signing Key, KSK).
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:
- The RRSIG record
- The NSEC and NSEC3 record
- The DNSKEY and DS record
- 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. Continue reading ‘DNSSEC – The DNSKEY and DS record’ »
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:
- The RRSIG record
- The NSEC and NSEC3 record
- The DNSKEY and DS record
- Implementation
While the RRSIG record allows you to verify the authenticity of returned records, there is still a gap remaining. What if the requested name does not exist? Since the DNS server replies with an empty answer section, there is nothing to sign. That’s where NSEC (or its brother NSEC3) comes into play. An NSEC record (Next SECure) states the range of names that do not exist. By signing this NSEC record by a corresponding RRSIG record, one can prove that a domainname does in fact not exist.
Continue reading ‘DNSSEC – the NSEC and NSEC3 record’ »
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:
- The RRSIG record
- The NSEC and NSEC3 record
- The DNSKEY and DS record
- Implementation
The RRSIG record is the basic building block of DNSSEC. It accompanies every Resource Record Set (RRset) and provides a digital signature over the provided data. This record is only supplied if the client indicates that it understands DNSSEC. A client does so by setting the DO (DNSSEC OK) flag (part of EDNS). If the server adds this record, it can be used to prove that the received data is authentic and hasn’t been tampered with (or prove the opposite). If, on the other hand, the response doesn’t contain RRSIG records, there are two possibilities. Probably the zone just doesn’t use DNSSEC, but it’s also possible that the response has been tampered with and had its RRSIG removed. Unless you have some prior knowledge, it’s impossible to know which case you’re in. This should be solved once the root-zone becomes signed in July 2010.
