How-to sort out a problem related to the RFC 7344, Sec. 3 & Sec. 5.

Managed DNS Hosting
1

Dear Team.

Thanks for the providing worldwide best of the best DNS hosting.

My question is how-to sort out a problem related to the RFC 7344, Sec. 3 & Sec. 5.

Scr. attached.

Thanks.

lvua.online-2024-09-27-09_17_32-UTC
lvua.online-2024-09-27-09_17_32-UTC1413Ă—1183 107 KB

2

Hi,

Thank you for your message, and welcome to deSEC! :slight_smile:

This is actually not a problem. Here’s why:

DNSSEC requires the domain’s validation key to be linked in the parent domain. This is done by publishing a hash of the key, which is called “DS record”. There are different hash algorithms, so several DS records are possible for the same validation key.

The hash algorithms have numbers; common ones are number 2 (which is the SHA-256 algorithm) and number 4 (SHA-384).

RFC 8624 Section 3.3 lists which hash algorithms should or should not be supported in software implementations. As you can see in the table there, algorithm 2 “MUST” be used in DNSSEC delegations (= published in the parent domain), and algorithm 4 “MAY” be used (additionally, that is).

For your domain, only one DS record (for algorithm 2) has been published. That’s completely fine and not a problem. In fact, when we display DS record information in our web interface, we only show the DS record for algorithm 2, because we have found that otherwise some users will skip algorithm 2 and only use algorithm 4, which is not a valid configuration (see above).

However, there’s an automatic mechanism for provisioning DS records (RFC 7344, to which the DNSViz warning relates). It works by publishing DS information in the child domain, as CDS records, which the parent can then copy. For these CDS records, we publish both algorithms 2 and 4, so that the parent domain can pick what they want.

This can result in the “inconsistent” situation that the parent only publishes algorithm 2, while we publish 2 and 4 via the CDS record set. While that is not a problem, the DNSViz checker still emits a warning. We think this warning is not helpful (because the configuration is completely valid, and there’s no risk to warn about). It would therefore be an improvement to DNSViz if this warning was not shown.

Now, one could wonder whether algorithm 4 is better than 2. The answer is that DNSSEC relies on algorithm 2 in a lot of other contexts (for example, for proving the non-existence of a subdomain), so it’s already baked in the system; if algorithm 2 is broken, then using algorithm 4 in a DS record will not save you. In addition, algorithm 2 is supported by all validators while algorithm 4 is less widely supported. Because there effectively is no security downside, it therefore makes sense to maximize compatibility, and use algorithm 2.

Stay secure,
Peter

2 Likes