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

Mark Andrews marka at isc.org
Wed Mar 10 23:29:33 UTC 2021



> On 11 Mar 2021, at 10:03, Evan Hunt <each at isc.org> wrote:
> 
> 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.

5431.   [func]          Reject DS records at the zone apex when loading
                        master files. Log but otherwise ignore attempts to
                        add DS records at the zone apex via UPDATE. [GL #1798]

> --
> Evan Hunt -- each at isc.org
> Internet Systems Consortium, Inc.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org




More information about the dns-operations mailing list