On 11/4/24 14:24, Roy Arends wrote:
The DS record already indicates if a delegation is secured and, if so, provides a signed digest over the secure entry point of the delegated zone. In theory, the digest function could be as simple as an identity hash function (where pre-image equals the output). The result of this function would be the alias FQDN. This alias FQDN serves as the secure entry point for to the delegated zone. While I thought this was an original idea when I heard it during the DELEG discussions, it has been proposed by both Peter van dijk (see below) and Paul Wouters independently (I've seen a draft for it, named "ds uplifting", though not in the datatracker, alas), and have heard today in the hallway that others have suggested it as well. This proposal allows validators to do the DS aliasing, and resolvers to do DELEG. A nice separation of functionality IMHO.
When considering multi-signer DNSSEC setups, it seems complicated to have the DS (key parameters) and DELEG (transport parameters) aliasing disentangled. This gets particularly complicated when using multiple signing algorithms. Although still in the future, a reasonable requirement for such scenarios would be that each signer uses at least one "universally" supported algorithm (currently 8 and 13). If a signer does not adhere to that, but DS and DELEG aliasing is done independently, it becomes much more complex to figure out what's going on and who's violating which requirement, especially when the DS and DELEG alias targets aren't obviously related. It's also not clear how CDS/CDNSKEY stuff works, then. (Where do they live? Do parents follow (C)DS aliases to enforce the continuity rule of RFC 7344 Section 4.1?) Probably more edge cases lurking. :-) To be clear, I like the idea; I just think that multi-party and multi-algorithm scenarios need to be considered from the start to arrive at a full solution. Best, Peter _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
