[DNSOP] Re: Delegation verification

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]