breaks on unknown DNSSEC algorithms in DS records

In Januari of 2019, I reported (via your upstream for Knot Resolver, CZNIC), that weird-ds1.7bits.nl did not resolve. That was fixed in Knot, and in April of 2019 I noticed that could resolve it again.

Today, I got a report that weird-ds1.7bits.nl (and weird-ds.nohats.ca) again do not resolve via

Can you fix this regression? Thank you!

Hey, thanks for responding! The domain’s DNSSEC configuration is unusual, but not broken. The DS points to an undefined DNSKEY algorithm, which resolvers are expected to treat as insecure, not as broken. DNSViz is buggy in this situation. confirmed this bug two years ago but still has not rolled out a fix. Knot Resolver confirmed this bug two years ago, released a fix (that deployed at the time), but for some reason this bug is back in your code base. PowerDNS Recursor, ISC BIND and NLnetlabs Unbound all handle this domain correctly (by treating it as insecure).

1 Like

Looking at the domain name, the configuration is probably designed as a test case for particular DNSSEC configurations.

@Habbie when you say that the configuration should be treated as insecure, do you expect a validating resolver to treat the configuration as if the zone was not signed at all?

1 Like

Hi @Habbie ! The issue is the DS exists (with unknown key algorithm) but there’s no matching key in the child zone. If the zone was signed and you had an extra DS with unknown algorithm, it would work. If the zone had a DNSKEY matching the DS with unknown algorithm, it would also work. I’m not saying it’s right, but I can’t find guidance for that in the RFCs, perhaps we can put that in the DoT discovery draft? 4035 says:

A resolver SHOULD believe that a zone is signed if the
   resolver has been configured with public key information for the
   zone, or if the zone's parent is signed and the delegation from the
   parent contains a DS RRset.

So it seems reasonable to assume that the zone should have a DNSKEY?

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, failed on weird-ds1.7bits.nl; then I reported it to Knot Resolver, they fixed it, and later in 2019, resolved the domain again; so apparently a later change ‘broke’ things again!

That helps! Either way, I can see why going insecure would be more useful than failing in this case, we’ll try to add an exception for this situation in the next rollout.

Thanks Marek! Any idea when that might be? It is not urgent of course.

One could argue for SERVFAIL for Do53 and going insecure for DoT with friends

That quote appears to be about the number zero, in the context of a private record that BIND uses for keeping track of signing. It has very little to do with this conversation :slight_smile:

I answered this in breaks on unknown DNSSEC algorithms in DS records - #10 by Habbie - I’m trying to pave the way for these proposals that use DS for other purposes than DNSSEC signing.

(Incidentally, all open source validating resolvers do accept these records.)

Most likely next week, I’ll update the thread.

My router checks for a properly keyed DNSSEC for each site I visit. If it fails, no site. (unrelated, but still…)

@Habbie this should be resolving now

Yep, noticed it yesterday already, but wanted to wait for your message, thanks! I see now that I forgot to mention weird-ds2.7bits.nl which has an invalid DS digest algo (but a valid DNSSEC algo, and no DNSKEYs), which also does not resolve (it’s another entire discussion, and I apologise for not mentioning it earlier in the thread). What are your feelings on that one?

Yeah, no problem. Currently the only digest algorithms downgraded to insecure status are according to the rfc8624 guidance. Do you have a use case for this?

No - all the wild ideas I’ve had, and have seen, that involved a ‘new’ digest also involved a new DNSKEY algorithm, so the change you already deployed covers that.