I really don’t see the need for dry run at all as hundreds of thousands of zones have been signed without it but if is going to exist we don’t need to half the small code point space which is the natural result of not doing something like I’m suggesting.
One can test if the zone is properly signed by installing trust anchors in recursive servers you control and have your applications use them. This is much less complicated than expecting validators to be updated to soft fail on this/these new algorithm(s). They are already complicated pieces of software that have to check lots of things. Adding more to this will make them even more complicated. Remember answers come from multiple zones and they depend on even more zones. DMARC is trivial compared to DNSSEC validation. What does it mean if a parent zone turns on dry run? People keep mentioning DMARC. That is trivial compared to this. -- Mark Andrews > On 18 Jul 2024, at 18:47, libor.peltan <libor.pel...@nic.cz> wrote: > > > My point was that > > example.com. IN DS 49172 13 130 > e2c8c32fb3c40586e0dabc367bfde4368b8dff52a7ffc60f619c720ec7767320 > example.com. IN DS 49172 13 2 > e2c8c32fb3c40586e0dabc367bfde4368b8dff52a7ffc60f619c720ec7767320 > > is more equivalent (i.e. the change from the first to the second looks safer > and more straightforward) than > > example.com. IN DS 49172 13 7 > 02e2c8c32fb3c40586e0dabc367bfde4368b8dff52a7ffc60f619c720ec7767320 > example.com. IN DS 49172 13 2 > e2c8c32fb3c40586e0dabc367bfde4368b8dff52a7ffc60f619c720ec7767320 > > /Libor > > Dne 18. 07. 24 v 10:27 Mark Andrews napsal(a): >> It would look like a regular DS. The only difference would be that the first >> byte of the digest would contain the sub type. This is just internal >> structure of the digest.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
