On Mon, Feb 19, 2024 at 6:55 PM Paul Wouters <p...@nohats.ca> wrote:
> On Sat, 17 Feb 2024, Shumon Huque wrote: > > I'm sure other folks will chime in with their views. But I want to ping > Paul Wouters specifically - since you are one of > > the expert reviewers for this registry and an author of > domain-verification, could you express your opinion on the > > specific request related to ACME (a pre-existing entry in that registry) > and its new scoped challenge specific labels. > > That registry is really weak. first come first serve. In theory, I > wouldn't technically be able to stop someone else from registering > _acme-elvis-my-way-challenge. > > The main goal of the registry is to avoid people inadvertently using the > same name. As such, I might push back a little on very generic names, > but things which clearly carve a namespace for general use like _acme, > are fine. > Thanks! > Now speaking as author, not as the underscore registry expert: > > I'm not sure you would want the host/wildcard/domain difference in the > QNAME though, because that might end up needing 3 DNS queries to find > out. It would be best if things could come in with 1 DNS query. Make > the variable part live in the RRdata, not the QNAME. > Yup, I agree that would be better. The DCV draft already has other examples of expressing application specific characteristics in "name=value" attributes of the resource record data (such an "expiry" attribute). Perhaps, we can propose a "scope=" attribute, that can take on the 3 possible values of host/wildcard/domain. e.g. _acme-challenge.www.example.org. 300 IN TXT "gfj9XqxxxxxxRg85nM scope=wildcard" or, _acme-challenge.www.example.org. 300 IN TXT "gfj9XqxxxxxxRg85nM" "scope=wildcard" Eric (Nygren) - was there a compelling reason to encode the scope into the qname label? Otherwise, I'm inclined to propose this change in the draft. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
