Abstract
It seems like every service wants proof you control your domain.
Certificate authorities need it to issue certificates. Email platforms need it to authorize sending. Analytics needs it to gather data. Just add this magic TXT record to your DNS, wait for propagation, click verify.
It works fine when it’s a one-time setup, but certificate lifetimes are dropping to 47 days, and you won’t be able to keep up on that schedule. You’ll have to automate, and now dozens of systems are changing your DNS.
The credential problem
DNS validation works by proving you can modify records in a zone. You add a special TXT record, the service queries for it, validation complete.
To do that automatically, you need API credentials. And most DNS providers don’t offer fine-grained permissions. You can’t say “this token can only create TXT records at _acme-challenge.example.com.” You hand over credentials that can modify your entire zone.
Now multiply that across every system that needs DNS validation to renew its certificate. That’s a huge attack surface. Each one capable of redirecting all your traffic, intercepting all your email, or poisoning your DNS entirely.
What is delegated domain validation?
But there’s a better way! Instead of giving each service credentials to modify your DNS, you can delegate just the validation record to them.
Say a service needs to validate _acme-challenge.example.com. Instead of giving it DNS API access, you create a single CNAME record:
_acme-challenge.example.com. IN CNAME abc123.challenges.certkit.io.
That’s it. One record, set one time.
When a service needs to complete a validation challenge, they don’t touch your DNS at all. They update a TXT record in their own zone at abc123.challenges.certkit.io. When the validating party queries _acme-challenge.example.com, DNS follows the CNAME and finds the current challenge token updated by CertKit.
You’ve delegated the validation, not the zone.
That abc123 is a unique token that binds this delegation to your specific account. If you ever stop using the service and remove the CNAME, nobody else can claim that validation target and start issuing certificates for your domain.
The IETF is formalizing this pattern in an upcoming Best Current Practice document, Domain Control Validation using DNS.
Delegated domain control validation lets a User delegate the domain control validation process for their domain to an Intermediary without granting the Intermediary the ability to make changes to their domain or zone configuration.
You’re proving control of your domain without giving anyone else control of your domain.
Why CNAME delegation is safer
With traditional DNS validation, your certificate service holds credentials that can modify any record in your zone. If those credentials leak, an attacker can do anything: redirect your website, intercept your email, issue fraudulent certificates for your domain.
With CNAME delegation, the worst case is different. If your certificate provider is compromised, an attacker can respond to validation challenges for your domain. That’s bad, but it’s bounded. They can’t redirect traffic that isn’t already going through that provider.
Related, the ACME working group is developing DNS-PERSIST-01, a new validation method addressing the operational and security risks of domain validation. Instead of proving control ‘right now’ with a fresh challenge, DNS-PERSIST-01 lets you set a persistent authorization record once. Combined with CNAME delegation, nothing changes on any renewal. Ever.
How CertKit handles this
CertKit uses CNAME delegation for DNS validation. You point your _acme-challenge record to us once, and we handle every certificate validation from there.
You never give us credentials to your DNS provider. We can’t touch your zone. We can only respond to ACME challenges for domains you’ve explicitly delegated to us.
Your DNS zone stays yours. We just handle the certificates.
CertKit automates certificate lifecycle management.
Comments