On Wed, Aug 18, 2010 at 5:30 AM, Phil Mayers <p.may...@imperial.ac.uk> wrote: > > After a bit of investigation, it seems that the problem is a missing > NSEC/NSEC3 record in the empty reply for: > > $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds > > ...since the "ncbi" zone is an unsigned child zone, there needs to be an > NSEC/NSEC3 record to prove the absence of the DS record, and have a secure > delegation to an unsigned child zone. >
The problem was that three out of the five servers authoritative for nlm.nih.gov were serving a version of the zone that did not include DNSKEY RRs or any other DNSSEC-required RRs (RRSIG, NSEC3, etc). If your resolver queried any of those three it got a response, but it was incomplete. This has been a fairly common problem among new DNSSEC deployments. Sometimes the problem is a slave that is not DNSSEC capable. Sometimes it's a slave not NSEC3-capable serving a zone signed with NSEC3 (which creates the issue for insecure delegations). In this case, I'm pretty sure the servers are capable of DNSSEC because they are serving the signed nih.gov zone just fine, so perhaps they got their nlm.nih.gov zone data from the wrong place. Often, BIND users don't notice these types of errors because BIND makes a special effort to find a valid response, if validation is enabled. However, if your validating server is behind an upstream proxy DNS recursive server, you may not have that choice. Likewise, a zone may not have the redundancy administrators think it has if you're only getting valid DNSSEC responses from a fraction of your authoritative servers. Regards, Casey _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users