Re: [dns-privacy] Next steps for draft-rescorla-dprive-adox

To Paul's point, this is the ICANN Base Registry Agreement listing the
permitted "TLD Zone Contents".

https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#exhibitA.1

This is only for gTLDs that have signed this agreement.  The ccTLDs
generally have their own contracts which will vary.

This idea could or should work for all authoritative domains that are not
TLDs.

tim

On Tue, May 11, 2021 at 9:37 PM Paul Wouters <paul@nohats.ca> wrote:

> 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
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>