[dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?

[Evan Hunt]

On 11 Mar 2021, at 06:29, Peter van Dijk <peter.van.dijk at powerdns.com> wrote:
> My vague suspicion is that BIND is flagging this as an impossible
> situation, because a DS should live in the parent, and only in the
> parent.

Your vague suspicion is correct - the presence of the DS bit in the NSEC3
for the apex node is causing named to decide it's not valid as a closest-
encloser proof.

RFC 5155 says:
| Once the closest encloser has been discovered, the validator MUST
| check that the NSEC3 RR that has the closest encloser as the original
| owner name is from the proper zone.  The DNAME type bit must not be
| set and the NS type bit may only be set if the SOA type bit is set.
| If this is not the case, it would be an indication that an attacker
| is using them to falsely deny the existence of RRs for which the
| server is not authoritative.

We seem to have added a check for the DS bit here as well, and Mark and I
are currently bickering in a side channel over whether that was a mistake
that should be fixed or not. Maybe we should be asking other validators
to flag this as an error, rather than making it work in BIND.

What's definitely true is that the DS at the zone apex is wrong. The
zone shouldn't have loaded that way.

> I recall isc.org 'recently' had a DS at the apex of the child zone; I
> wonder if after ISC removed that, they made BIND, as a validator,
> stricter about it when detected.

Hm, I don't recall that, but it may be so. But, the BIND validator has
had this restriction since NSEC3 support was first added in 2008.

--
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.