[dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?
Matthijs Mekking
matthijs at pletterpet.nl
Thu Mar 11 08:21:58 UTC 2021
On 10-03-2021 20:29, Peter van Dijk 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'.
It is more wrong than useless: From RFC 4035:
All DS RRsets in a zone MUST be signed, and DS
RRsets MUST NOT appear at a zone's apex.
- Matthijs
>
>>> 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,
>
More information about the dns-operations
mailing list