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

[Matt Nordhoff]

On Tue, Jun 22, 2021 at 3:54 AM Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> On Tue, Jun 22, 2021 at 03:30:39AM +0000, Matt Nordhoff wrote:
>
> > > 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>:
> >
> > 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.
>
> No, there's a subtle difference, this qname actually exists, and has an
> NS RRSet.  The NSEC bitmap needs to reflect this.

Ah, now I understand the issue, thank you.

I'm sorry if my previous email seemed glib. I didn't get enough sleep
to easily understand NSEC problems, but thought it was probably better
to reply now than to wait.

My email might still matter, but it's not relevant to this thread.

[FWIW, Cloudflare handles insecure referrals correctly, AFAIK. I have
no idea about NS1, but there's no reason to suspect anything.]
-- 
Matt Nordhoff