I'll let other authors and the WG also speak to it, but a big reason to leave this out is that the current draft is intended to be a best current practice.
Are there cases of NS record based validation being used in production? It seems like something new which would preclude it being in something aiming to be a BCP. There are numerous other things that I also wanted to see in this draft (eg, addressing the scope confusion risk) but where we removed the text since it also was something new rather than a current practice. For validating of domains using NS records, at least for the case with validating newly registered domains I feel that it will be important to socialize the draft/proposal with stakeholders such as registrars prior to publication. That will also be harder under time pressure, but I think the major factor is this being something new rather than a current practice. That the issue was opened in 2024 and explicitly tagged as "future" was intentional. There was time to have included it, but we chose not to so as to bound scope and as it is something new. A bunch of the other "future" tagged issues are similar. Best, Erik On Thu, Jun 18, 2026 at 12:20 PM Peter Thomassen <[email protected]> wrote: > Hmm. I'd rather say as > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/147 > was opened mid-2024, there was ample time to address it. The fact that it > hasn't happened IMO doesn't make it out of scope. > > While I don't see behind the curtains what's gained from publishing this > quickly (which generally I feel is a laudable goal!), I also feel like it > would be better to have one go-to document about domain verification things > instead of two. > > Perhaps if you could share what would be the downside in a small delay, > that would help make me shut up ;-) > > Best, > Peter > > > On 6/18/26 18:05, Erik Nygren wrote: > > My concern on adding this in is more about all of the supporting stuff > needed to get this right. > > The actual "how do to this" is probably a paragraph as you say. > > > > But the security considerations and other operational issues are going > to be non-trivial to get right. > > > > Our current plan is to submit a near-final draft in the next day or two > and try and suggest the chairs to do WGLC of that version (or to pass on if > the chairs/WG think that the previous WGLC was good enough). > > We really want to get this out the door since it has been dragging on > for so long and each thing we add just adds risk. > > > > Erik > > > > > > > > On Thu, Jun 18, 2026 at 11:59 AM Peter Thomassen <[email protected] > <mailto:[email protected]>> wrote: > > > > Hi Erik, > > > > On 6/10/26 19:25, Erik Nygren wrote: > > > I agree that this use-case is something we do want to handle, > especially as way to be able to indicate to authorize/validate > > > provisioning DNS authoritative services for a domain as the > normal ways don't work for this. > > > > > > My inclination however is that we want to split this out into its > own separate draft. I think there are enough > > > design discussions that want to happen here (eg, > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/147 > < > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/147> > < > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/147 > < > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/147>> > discusses > some) > > > > In fact, the issue you cite proposes the same solution as I did, > albeit for a different use case (preventing lame delegations as opposed to > 2FA recovery). The common aspect, however, is domain holder verification. > > > > In my earlier message, I suggested that this could be a simple > addition of one or two paragraphs to the draft. For example, something like > the 4th paragraph in the issue you referenced would probably suffice. > > > > Such a small addition distinctly, I think, would not justify the > overhead of an additional document process. > > > > If the WG has no objections, I can offer such a small addition next > week. If it's uncontentious, we might as well ship it; if it is contentious > / holding things up, we can still drop it. > > > > Best, > > Peter > > > > -- > Like our community service? 💛 > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Möckernstraße 74 > 10965 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
