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 [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
