On Tue, 11 May 2021, Eric Rescorla wrote:
From my perspective, the primary open question is the wisdom of having some kind of record in the parent domain.
While I understand that there are people who have reservations about whether it will be practical to popuate the parent
This is not about some people having reservations. As I explained before, you are talking about: - Updating DNS resolvers understand a new DS-like record on the 'wrong' end of the zone cut (incompatible with RFC 3597) - Updating DNS auth server code to serve a new DS-like on the 'wrong' end of the zone cut (incompatible with RFC 3597) - Update all the DNS servers run these new DNS resolvers - Adding a new EPP extension to transport the new record to the Registrar - Adding a new EPP extension to transport the new record from the Registrar to the Registry - Registrars updating their code (libraries and webgui) - Registries updating their code (libraries) - Updating ICANN contracts about allowed RR types - Writing CDS/CDNSKEY style auto-updating for this new record - Updating zone file verification tools to not barf on record being out of bailiwick Last time, I recommended you talk to people at the REGEXT working group, Registries/Registrars and DNS hosters, our ICANN liaison or SSAC. Did you contact any of these people to ask about the feasability of your proposal?
2. Is this proposal a plausible starting point for that?
No it is not. If a TLD that falls under ICANN policues would suggest running software that supports this proposed record, it would surely trigger an RSTEP review, and wearing my ICANN RSTEP reviewer hat, I would strongly advise not reject the TLDs technical proposal. This has nothing to do with what I want. I _want_ this record or similar solution to work, but it just realistically cannot work. That is also why people (including me) who are normally very strict against overloading have suggested the only way to signal something at the parent is via overloading the NS or DS record in some way. And using DS is better because it is signed and can be verified at the child. Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
