> On Dec 2, 2022, at 1:49 PM, Hollenbeck, Scott
> wrote:
> I lean towards "prohibited means prohibited". DNS service providers can be
> compromised, too, and I'd prefer to see steps taken to explicitly remove the
> state prior to a DNS update vs. allowing some actors to bypass the state.
Exact
Yes, because the registry can improve over time, and the registrars can update
their software over time. If we don’t give updated client-side software a
mechanism to discover that the server now supports improved transport, we get
gridlock.
-Bill
> On Mar 20, 2024, at 3:4
The. Certificate problem can be dealt with as elsewhere: switch to DANE and
stop accepting CA certs.
-Bill
> On Mar 20, 2024, at 5:33 AM, Francisco Obispo wrote:
>
> This is a neat idea,
>
> Is there a reasoning or use case for such need?
>
> One of the challenges that
> On Mar 20, 2024, at 08:50, Jim Reid wrote:
>> On 20 Mar 2024, at 07:04, Bill Woodcock wrote:
>> Yes, because the registry can improve over time, and the registrars can
>> update their software over time. If we don’t give updated client-side
>> software a mec
We’d be _very interested_ in seeing a standardized, end-to-end registry-locking
model. Specifically, one in which the registrant signs change requests, and the
registry validates the signatures, and nobody in the registrar path is involved
in any way.
Lack of end-to-end protection was one of t
> On Apr 8, 2021, at 10:04 AM, Quoc@registry.godaddy wrote:
> I want to note as well that the "domain registry" and "DNS" aren't
> necessarily the same system as a TLD may not use the DNS service of the RSP
> or the RSP may not offer a DNS hosting for the TLD.
Yes, that’s correct. Each TLD wi
