[dns-operations] TLD .law - non-signing KSK with referenced DS

[Matt Nordhoff]

On Wed, Jan 19, 2022 at 1:34 PM Einar Bjarni Halldórsson <einar at isnic.is> wrote:
> On 14.1.2022 10:30, Viktor Dukhovni wrote:
> > On Fri, Jan 14, 2022 at 10:09:04AM +0000, Matthew Richardson wrote:
> >
> >> Looking visually at the DNSViz output, the KSK 16819 does look strange as
> >> it is referenced by a DS but does not sign anything.
> >>
> >> Out of interest, do folks think this is a valid configuration?
> > Looks valid to me, because another KSK for the same algorithm and
> > choice of hash does sign the DNSKEY RRset:
> I thought it was just the same algorithm, not necessarily the same hash
> type?
>
> We're finishing up a test migration of a signed zone, doing a key
> rollover, and the old DS record is algorithm 8, digest type 2. The new
> key has two DS records, both algorithm 8, one digest type 2, one type 4.
>
> We saw the error in zonemaster, but DNSviz and probes in RIPE Atlas
> never flagged an error.
>
> .einar

RFC 4509 (SHA-256 DS) section 3 [0] says:

"Validator implementations SHOULD ignore DS RRs containing SHA-1
digests if DS RRs with SHA-256 digests are present in the DS RRset."

Skimming RFC 6605 [1] -- which was nominally about ECDSA DNSKEYs but
also added SHA-384 DS -- I don't see anything directly about that, but
it does incorporate 4509's Security Considerations [2], which are
entirely about the DS downgrade issue.

PowerDNS Recursor used to ignore SHA-256 records in the face of
SHA-384 records, but this was considered a bug and recently fixed. [3]
I don't know if any other resolvers behave the same way. It would be
prudent not to chance it.

[0]: <https://datatracker.ietf.org/doc/html/rfc4509#section-3>
[1]: <https://datatracker.ietf.org/doc/html/rfc6605>
[2]: <https://datatracker.ietf.org/doc/html/rfc4509#section-6>
[3]: <https://github.com/PowerDNS/pdns/pull/10908>
-- 
Matt Nordhoff