www.ncbi.nlm.nih.gov / pubmed

[Casey Deccio]

On Wed, Aug 18, 2010 at 5:30 AM, Phil Mayers <p.mayers at 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