[dns-operations] Inconsistent NSEC response for unsigned zone from AWS

[Matt Nordhoff]

On Tue, Jun 22, 2021 at 12:36 AM Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> On Mon, Jun 21, 2021 at 07:45:44PM -0400, Puneet Sood wrote:
>
> > $ dig corp.ibexglobal.com -t NS +dnssec +nocrypto +nocomment @ns-725.awsdns-26.net.
> >
> > ;corp.ibexglobal.com.           IN      NS
> > corp.ibexglobal.com.    172800  IN      NS      ns-1415.awsdns-48.org.
> > corp.ibexglobal.com.    172800  IN      NS      ns-1804.awsdns-33.co.uk.
> > corp.ibexglobal.com.    172800  IN      NS      ns-29.awsdns-03.com.
> > corp.ibexglobal.com.    172800  IN      NS      ns-945.awsdns-54.net.
> > corp.ibexglobal.com.    86400   IN      NSEC    \000.corp.ibexglobal.com. RRSIG NSEC
> > corp.ibexglobal.com.    86400   IN      RRSIG   NSEC 13 3 86400 20210623002754 20210621222754 36517 ibexglobal.com. [omitted]
>
> Indeed I see the same:
>
>     $ dig +noall +dnssec +norecur +nocrypto +ans +auth +add -t NS corp.ibexglobal.com @ns-725.awsdns-26.net.
>     corp.ibexglobal.com.    172800  IN      NS      ns-1415.awsdns-48.org.
>     corp.ibexglobal.com.    172800  IN      NS      ns-1804.awsdns-33.co.uk.
>     corp.ibexglobal.com.    172800  IN      NS      ns-29.awsdns-03.com.
>     corp.ibexglobal.com.    172800  IN      NS      ns-945.awsdns-54.net.
>     corp.ibexglobal.com.    86400   IN      NSEC    \000.corp.ibexglobal.com. RRSIG NSEC
>     corp.ibexglobal.com.    86400   IN      RRSIG   NSEC 13 3 86400 20210623012420 20210621232420 36517 ibexglobal.com. [omitted]
>
> This violates <https://datatracker.ietf.org/doc/html/rfc4035#section-2.3>:
>
>    ...
>
>    An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
>    RRset at any particular owner name.  That is, the signing process
>    MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
>    the owner name of any RRset before the zone was signed.  The main
>    reasons for this are a desire for namespace consistency between
>    signed and unsigned versions of the same zone and a desire to reduce
>    the risk of response inconsistency in security oblivious recursive
>    name servers.
>
>    ...
>
>    The bitmap for the NSEC RR at a delegation point requires special
>    attention.  Bits corresponding to the delegation NS RRset and any
>    RRsets for which the parent zone has authoritative data MUST be set;
>    bits corresponding to any non-NS RRset for which the parent is not
>    authoritative MUST be clear.

I haven't spent the time to understand precisely what this thread is
talking about, but that's how NSEC white/black lies work. NS1 does the
same thing (give or take possible bugs) as AWS.

Cloudflare's implementation is slightly different but also has NSEC
records like this. (Cloudflare's "NSEC shotgun" 'NODATA' records put
every record type they support in the bitmap; their 'NXDOMAIN' records
just set NSEC and RRSIG).

I note that RFC 7129 is informational and updates no other RFCs.

$ dig +dnssec nxdomain.cloudflare.com | awk '$4 == "NSEC"'
nxdomain.cloudflare.com. 300    IN      NSEC
\000.nxdomain.cloudflare.com. RRSIG NSEC
$ dig +dnssec nxdomain.ns1.com | awk '$4 == "NSEC"'
nxdomain.ns1.com.       3600    IN      NSEC    \000.nxdomain.ns1.com.
RRSIG NSEC
-- 
Matt Nordhoff