Implementing DNSSEC Validation
May 27 2009 by 
Cricket Liu (Infoblox)
This may be obvious to some of you, but implementing DNSSEC validation is easy if you use a forwarding architecture (that is, if you resolve Internet domain names using forwarders). Only your forwarders need special configuration, and that configuration is simple.
First, you need to make sure those forwarders are running the latest code. The gov zone is signed using something called NSEC3 records, so you'll want a name server that groks those. If you're running BIND, that's BIND 9.6.0 or better.
Next, you need to enable DNSSEC on those forwarders. Add these two substatements to your options statement:
options {
dnssec-enable yes;
dnssec-validation yes;
};
Finally, configure trust anchors for the signed zones you'd like to validate. You can retrieve a list of the TLDs that are signed from IANA's Interim Trust Anchor Respository, or ITAR. IANA helpfully provides a script, called anchors2keys, that you can use to convert the DS records published in the ITAR to the format BIND expects.
Done? Just reload your name server and you're validating signed records!
Posted in DNSSEC | DNS Best Practices | 
2 comments
May 27, 2009 at 1:48 PM
Probably also worth mentioning that validation errors will give you an SERVFAIL response which may be a surprise to some people and can make troubleshooting a challenge. dig with +dnssec and +cd are your friends :)
May 27, 2009 at 2:08 PM
Absolutely correct. This configuration should have no adverse effect on unsigned zones (which means most of the zones in the world) or on signed zones that validate correctly, but if the administrator of a signed zone chokes and forgets to re-sign before his signatures expire, muffs a rollover, or makes any one of many possible mistakes, your forwarder will return SERVFAIL. On the other hand, that's just DNSSEC doing its job - those could be the symptoms of an attack!