[dns-operations] Inconsistent NSEC response for unsigned zone from AWS
mnordhoff at gmail.com
Tue Jun 22 04:31:54 UTC 2021
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.]
More information about the dns-operations