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 discusses some) and we really need to actually wrap up draft-ietf-dnsop-domain-verification-techniques and get the core draft published. Best, Erik On Sun, Jun 7, 2026 at 12:23 PM Shumon Huque <[email protected]> wrote: > On Wed, Jun 3, 2026 at 2:44 PM Peter Thomassen <[email protected]> wrote: > >> Dear WG, >> >> We've been encountering a delegation control verification use case >> repeatedly at deSEC. It was only recently that I saw the more general >> connection to domain verification and >> draft-ietf-dnsop-domain-verification-techniques. >> >> Our use case is: as a DNS platform, folks delegate their domains to our >> nameservers. Sometimes, they loose access to their 2FA device, and also >> don't have recovery codes. In that case, we send them an email like the >> following: >> >> ---------------------------- >> I'm sorry to hear you lost 2FA access! >> >> Your recovery token is: 4ob73r542sea2oiqyllii >> >> To recover your domain(s), you need to prove control over them at the >> registration point, by adding an additional nameserver: >> >> <recovery-token>.dv.desec.io OR >> <recovery-token>.dv.desec.org >> >> Once proof of control has been given for all domains in your account, we >> will disable 2FA. If you can only prove control for some domains, we will >> move the others into a dummy account for later recovery before disabling >> 2FA. >> ---------------------------- >> >> *.dv.desec.io has the same addresses as ns1.desec.io, and *.dv.desec.org >> has the same addresses as ns2.desec.org. >> >> The recovery token is a secret shared with our user, and if it shows up >> in the delegation from the parent, we can reasonably assume that the domain >> owner is indeed our user. >> > > I think this is a reasonable approach. > > Not that this method of encoding a validation token in the delegating NS > set has a more general use case too, which the authors have discussed in > the past -- namely "initial" validation of control of the > delegation/registration, so that an adversary can't hijack the domain in > the window between when it was registered/delegated and when it was > deployed on a downstream managed DNS operator. Eric Nygren has an open > issue in the github repo of the draft on this: > > > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/147 > > Maybe we can generalize the solution to cover both cases. > > Unfortunately, this process doesn't work securely with all parents. In >> particular, some require the child-side NS to match the parent's, so we >> have to change our customer's NS records before they can make the change. >> However, that exposes the secret in public. This way, after a domain >> ownership change, the new owner may be able to take over an existing deSEC >> account (enumerating the zone, or learning about token configurations such >> as subnet ACLs which can serve as further attack intel). Also another >> child-side change is needed for reverting to the previous delegation NS >> after verification. >> > > Yes. The other issue is that many DNS zone validation tools will flag this > inconsistency as a misconfiguration. So, if we propose this method, it > probably needs to be time limited. > > Ideally, the validation token would be encoded in a new purpose built RR > type, but that can't be deployed in any reasonable amount of time.. Maybe > something for DELEG to consider as a parameter. > > >> I think it would be great if the document could note that our process >> outlined above is how you SHOULD do delegation control validation, and that >> the process SHOULD NOT involve publishing the validation nameserver >> hostname prior to using it for delegation. >> >> This probably can be said in 1-2 paragraphs, perhaps as a new section 9 >> ("Delegation control validation"). >> >> Would folks be OK with such an addition to the document? >> > > I'm open to incorporating something like this, but will wait for others to > chime in. > > Shumon. > >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
