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]
