On Thu, 12 Aug 2021, Joe Abley wrote:
I think the set of acceptable algorithms is constrained sufficiently often by
registries and registrars that it makes little sense to consider any other case.
I think this problem is more easilly solved. You can reach out to them.
So my own order of preference is likely something like:
1) Forget about protecting in-bailiwick nameservers
2) Do it securely using DS at parent
(only requires new code for validating nameservers that don't exist yet)
I don't understand what the parenthetical comment here means. You're suggesting
that existing validating resolvers that don't know how to interpret a weird
algorithm in a DS RRSet received during a referral don't need to be changed?
I'm saying that validators that support SVCB are not there yet, so when
adding SVCB support, they will also add the SVCB-via-DS support. So
the ramp-up will the ramp from "unencrypted resolvers" to "resolvers
with encrypted transport support". The DS hack does not delay that part.
And on the authoritative side, there is no protocol/code change
required (unlike the "SVCB at parent" solution)
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
