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.
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.
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?
Thanks,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
