Hey Marek! Yes, I’ve been pondering whether the DoT discovery draft should have words on this, or if this should be clarified separately via DNSOP. In conversation with another big resolver operator, our conclusion was that it’s possible to argue 4034+4035 both for ‘failure’ and ‘insecure’. Another big operator also suggested that a clarification document would be good to have.
The bit from 4035 5.2 that I think might help here is “If the validator does not support any of the algorithms listed in an authenticated DS RRset, then the resolver has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would the case of an authenticated NSEC RRset proving that no DS RRset exists, as described above.”
And indeed, I am doing this to pave the way for various proposals in DPRIVE and DNSOP, such as draft-vandijk-dprive-ds-dot-signal-and-pin-01 - Signalling Authoritative DoT support in DS records, with key pinning, draft-fujiwara-dnsop-delegation-information-signer-00 - Delegation Information (Referrals) Signer for DNSSEC and draft-vandijk-dnsop-ds-digest-verbatim-00 - The VERBATIM Digest Algorithm for DS records
What I find most interesting is that in January of 2019, 188.8.131.52 failed on
weird-ds1.7bits.nl; then I reported it to Knot Resolver, they fixed it, and later in 2019, 184.108.40.206 resolved the domain again; so apparently a later change ‘broke’ things again!