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

[Mark Andrews]

Done via the web page.

> On 11 Mar 2021, at 09:42, Mark Andrews <marka at isc.org> wrote:
> 
> And has anyone reported this to them?
> 
>> On 11 Mar 2021, at 09:37, Mark Andrews <marka at isc.org> wrote:
>> 
>> So who is correctly rejecting DS at top of zone at load time?  There is no way
>> to query for this RRset.
>> 
>>> On 11 Mar 2021, at 06:29, Peter van Dijk <peter.van.dijk at powerdns.com> wrote:
>>> 
>>> On Wed, 2021-03-10 at 16:44 +0000, Matthew Richardson wrote:
>>>>     9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se: type NSEC3, class IN
>>>>>         Name: 9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se
>>> 
>>> Which is the NSEC3 hash of 'prv.se.',
>>> 
>>>>>         Type: NSEC3 (50)
>>>>>         Class: IN (0x0001)
>>>>>         Time to live: 3600
>>>>>         Data length: 43
>>>>>         Hash algorithm: SHA-1 (1)
>>>>>         NSEC3 flags: 0
>>>>>             .... ...0 = NSEC3 Opt-out flag: Additional insecure delegations forbidden
>>>>>         NSEC3 iterations: 50
>>>>>         Salt length: 8
>>>>>         Salt value: 33e9285ab62c0803
>>>>>         Hash length: 20
>>>>>         Next hashed owner: 4f848f41f3884a3fc412e821e031cdd8b9a48eca
>>>>>         RR type in bit map: A (Host Address)
>>>>>         RR type in bit map: NS (authoritative Name Server)
>>>>>         RR type in bit map: SOA (Start Of a zone of Authority)
>>>>>         RR type in bit map: MX (Mail eXchange)
>>>>>         RR type in bit map: TXT (Text strings)
>>>>>         RR type in bit map: DS(Delegation Signer)
>>> 
>>> which apparently has a DS at the apex of the child zone, which is
>>> somewhere between 'useless' and 'wrong'.
>>> 
>>>>>         RR type in bit map: RRSIG
>>>>>         RR type in bit map: DNSKEY
>>>>>         RR type in bit map: NSEC3PARAM
>>> 
>>> Combined with
>>> 
>>>> 10-Mar-2021 16:20:11.606 dnssec: info: validating _dmarc.prv.se/TXT:
>>> bad cache hit (_dmarc.prv.se/DS)
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> Kind regards,
>>> -- 
>>> Peter van Dijk
>>> PowerDNS.COM BV - https://www.powerdns.com/
>>> 
>>> _______________________________________________
>>> 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
>> 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org
> 
> 
> _______________________________________________
> 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