What I noticed in reading this nice write up was the warning image they missed in the Route53 console because of the automation they use. But most folks use automation/tooling/etc in their workflow, and catching those warnings via automation is a bit tricky.
Right after this happened several different teams looking to sign their zones got a little nervous. This writeup helps to show people how things can break, but also, there is a great set of testing methods to assist others. Mark's comments about adding tests in DNSVIZ would be pretty great. tim On Wed, Dec 1, 2021 at 5:47 AM Philip Homburg <pch-dnso...@u-1.phicoh.com> wrote: > > Also stop hiding this > > breakage. Knot and unbound ignore the NSEC records which trigger > > this when synthesising. All it does is push the problem down the > > road and makes it harder for others to do proper synthesis based > > on the records returned. > > I'm confused what this means. In the report from Slack about the incident > I found that the problem started with a bad NSEC record, shown in their > debug output as: > > qqq.slackexperts.com. 2370 IN NSEC \000.qqq.slackexperts.com. > RRSIG NSEC > > This is returned in response to a AAAA query. The intent was that the NSEC > record should have the 'A' bit as well. > > What exactly do Knot and Unbound ignore in this case? > > Is it that they should have special processing for an NSEC that has only > RRSIG and NSEC and nothing more? > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
