[DNSOP] Re: Delegation verification

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]