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]
