DNSSEC not populating parent zone files with DS records

[Casey Deccio]

On Fri, Sep 30, 2011 at 6:16 PM, Hauke Lampe <lampe at hauke-lampe.de> wrote:

> Aside from the missing DS, I don't see why BIND complains about the
> NXDOMAIN response at first and then returns that cached record set in
> response to later queries for the same name. dig +sigchase validates it,
> if provided with the nau.edu DNSKEY:
>
>
The issue can be seen by querying the authoritative source, rather than what
the resolver returns.  As someone posted earlier, the cause of the issue is
the lack of NS RRs for extended.nau.edu in the nau.edu zone.  Prior to
DNSSEC deployment this wasn't really an issue (even though it was certainly
a misconfiguration) if all the authoritative servers for the parent zone
were also authoritative for the child zone.  In this case the parent
authoritative servers knew and could properly respond with the NS RRs.
However, the DS RR is a new beast, and even though it carries the name of
the child zone (e.g., extended.nau.edu), the parent zone (e.g., nau.edu)
answers authoritatively for that record type.  So when querying for DS vs.
other record types the responses are different:

$ dig @ns1.nau.edu extended.nau.edu ds | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39613
$ dig @ns1.nau.edu extended.nau.edu ns | grep status
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28073

DS queries in this case result in NXDOMAIN for the name because the parent
zone has no records of that name (because of the lack of NS RRs for the
child).  NS records, however, return NOERROR because the response comes from
the child zone which has records of that name.  The resolver returns
inconsistent responses based on its configuration (validation, which causes
querying for DS RRs) and the state of its cache.  The lack of NS RRs in the
parent is also shown in the DNSViz output for extended.nau.edu:

http://dnsviz.net/d/extended.nau.edu/dnssec/

Regards,
Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20111001/8817506a/attachment.html>