Service that automatically provisions CNAME redirection for DNS challenges


The idea, as I read it, is to only “proxy” the authentication. A la “CDN” type service.
No one complains when http authentications passing through Cloud Flare, nor when http authentications traverse the Internet (completely “unencrypted”).
In the event an API is used and some sort of authentication/validation is required to update the MITM DNS system, there is no need to re-use the same credentials used to authenticate/validate with LE (that would be weak).
My thinking is much less complicated…
In the CNAME DNS zone:
Allow any user to create an account.
Allow any account to insert (limited number of) challenge response records [perhaps within a subdomain that matches their account].
Expire those entries as needed - relatively short lived; minutes or hours, not days.
Any inserts to bad accounts or non-existent accounts would just automatically fail as there is no valid location for them to insert to.


The ACME client handles the normal workload.
The “CNAME DNS plugin” handles the TXT record creation only.
So it only needs to get passed the TXT record data only.
The plugin (creates an account with the CNAME DNS provider, if needed, and) requests the TXT record creation.
Loops on global DNS lookup for that TXT record (for specified time).
When record found, return back to ACME client to continue.
When record NOT found, then abort with error.


It’s all a matter of trust: who do you trust more? CloudFlare? Or @webprofusion? (Again, no offence. I think it’s a noble idea/project!)

Strictly speaking, any MITM could indeed get a certificate. Unless you’d chain your LE account to your domain and of course, your domain needs to have DNSSEC :wink:


I think your missing my point.
If done right, you treat them like you treat the entire Internet = untrusted.
And you still get a valid cert that you can use to secure your site.

But there is no (malice from any) MITM in a secure design.
As an example (which I have done myself): If you proxy outbound requests from your ACME client to [and you add your cert as trusted], you will see the cleartext requests and responses - which contain nothing that is secret; No private information is ever sent to LE.
Nor should it ever be sent to any DNS provider; nor anyone anywhere.
So the secret(s) remain secret(s) regardless of however many “MITM” may be present.



True, but I’m not refering to the information send to and from the CA. The problem is: if a third party can intercept the data stream, it can request a certificate independently from the actual owner of the domain from LE. LE will answer the request with: sure you can have a certificate from us, just please put this token somewhere (DNS, webroot). Then, the MITM can place this token somewhere in between (HTTP) or at the DNS proxy service and it’ll authenticate the challenge.
And sure, this is valid for every MITM situation. That’s why CAA account pinning was invented. That’s why LE checks DNSSEC records.
But when “offloading” trust, you should always carefully check to whom you’re offloading that trust to.


Thanks, I see the problem. LE doesn’t currently restrict the issuance of a cert for a domain to a specific LE account, so anyone can ask for a domain cert (for example) and if they can cause validation to complete (i.e.e the MITM updates the TXT record as required) then they get the cert.

Hmm, how to ensure trust? I could just say ‘trust me’ but that’s a sure sign not to trust someone!

Even if LE was the DNS redirection host, that necessitates having an account you actually administer rather than the more loose concept that LE currently has for an account. if someone then got your password/account access they could complete the loop and get a certificate.


But to intercept the conversation between the client and LE you have to break the client machine [to insert your root cert in their trust store] or actually have a valid cert for or force it to http.
What am I missing?
That the DNS CNAME service can issue a cert for ?
That is NOT a valid FQDN to be issued a cert.


I think the flaw noted here is that you don’t have to be running the same client, or the same LE account, or intercept anything in order to request validation for a specific domain (anybody can start a new cert request for any domain?). So the owner of the redirection service (or anyone who gains access) can see you’re using their service and which TXT record to update, then request a new cert and complete the validation using their own client.

To then make nefarious use of the cert is a different topic (like redirecting DNS queries etc), however.

Perhaps some sort of watchdog process (for unauthorised validation requests or extra cert issuance) or an independent audit is necessary.

My only worry would really be if providing such a service in some way compromises LE’s position as a CA, because they follow the redirection. The last thing we’d want is for CNAME redirection to have to be switched off as potential security flaw.


I think I’m starting to see the exploitability of this.

Anyone who controls your DNS, can already exploit that to create all kinds of certs for that domain (without extra safeguards)
Anyone who controls an IP you point any of your names to, can exploit that control to create a cert for that name using that IP as authentication.

I suppose that passing DNS authentication control (via CNAME) amounts to duplicating that DNS exposure; now to someone less… known. Although there are plenty well knowns that I would not trust with my DNS nor my emails.

So, if someone like “GoDaddy” was to offer such a service (for free) would anyone who doesn’t have a domain with them, and is experiencing DNS authentication issues, use that free service?
Would that be a foot-in-the-door for them to get your future DNS and domain registration service business?

Like “Are you having trouble with Company A DNS authentication services?”
“Why not TRY our DNS services for free and you don’t have to switch DNS providers nor even provide us with any credit card info. Simply point your authentication record to our DNS system.”


Yes, I do think CloudFlare et al would be well positioned to do this, and I’d quite like the API to be such that other services could just adopt the same endpoints/msg formats.

Regarding trust, every LE client in use today is in a massive position of trust, because if it wanted to it could just upload your new cert to the author who can then sell it to the highest bidder for whatever purpose.


Or any other piece of code that is installed could gain access to the certs and send them wherever.
Who reads every line of code and compiles every piece of software they run?
That said, we should never intentionally weaken our security stance.

The whole DNS API thing should be somehow standardized across all major DNS platforms; Then all DNS providers would be equal in that respect.
And this problem would no longer even exist.
Until then, people will continue to solve problems the best way they know how.
Changing DNS providers is probably the most effective - but most people don’t really understand the Internet and would not be able to make such a change without completely changing their entire (one-stop-shop) system setup.


Completely agree that DNS providers could have a single protocol for API operations if they got their act together, they’re mostly doing the same thing after all.


You don’t need to intercept anything, but the authorisation. I can request a certificate for your site from my own computer with any ACME client. I can request a certificate for, for I just can’t get the authentication to pass. Unless I can intercept the request for the token, asked by Let’s Encrypts validation server. Intercepting port 80 for requests to /.well-known/acme-challenge/ or the TXT record for Obviously, when the latter is being forwarded to my own DNS server, per current topic, the validation would be childs play.


This is true within all DNS systems : whomever runs the DNS, runs the show.

Nonetheless, there should be a lock and key system in place to ensure that only the keyholder gets certs issued to their domain.
So that anyone can use any available public DNS system and still feel safe about their domain certs.
How does that happen?
Do we need to develop a better (smarter) authentication system?

Trust and domain ownership validation

Which is entirely by design for domain validated certs. There’s really no other automated way to prove you own/control a domain and the CAB Forum is fine with this.

I don’t honestly think this is possible given the existing mechanics of owning a domain.

Huge portions of the Internet only really work because of trust. Trust in your web host not to tamper with or inject content into your traffic. Trust in your DNS provider not to create/modify records you didn’t ask for. Trust in your ISP to prioritize your traffic the same as everyone else’s. Trust in your browser to render pages properly based on the content they receive.

Certs are no different.


And yet certs “in action” require no trust from anyone in the middle…
Encryption overcomes the need for trust (from those in the path).
Everyday encryption is being applied to more and more systems/situations: DNSSEC, DKIM, PGP, etc.

The next step should include secure control despite the use of public resources.
Like don’t just upload a document to a “DropBox” service - encrypt it first; then it doesn’t matter where it is or who may see it.


Of course they do. The CAB Forum itself is just a collection of trusted organizations who the rest of us trust to decide who the trustworthy CAs are. The cert you trust is only trusted because the CA who signed it is part of a trusted list.

Without it, you don’t know that the your having an encrypted conversation with is the real or an imposter.

Some businesses breach that trust every single day by forcing your corporately controlled machine to trust their root CA explicitly so they can MITM your connections and inspect your traffic “for security”. Even some consumer AV/security products have been known to do this.


The CAs were not included in “in the middle”.
Obviously we must “trust” someone/somewhere.
The point is to minimize the amount of required trusts and to be able to use public systems just as we would use trusted systems.
Encryption accomplishes this everyday with TLS and VPN, etc.

Like some systems require two-factor auth and do so quite simply with SMS text messaging.
LE could allow one to add an additional two-factor auth.
Or simply require the auth token to be itself encrypted with the account key.
The token has no legible text, no real visible pattern to match - it would take a true brute force attack to crack the account key before anyone could use it elsewhere.

Here is the one-time specific cleartext token.
Now encrypt it and store it in any public DNS (that can be CNAMEd to any other public DNS).

Neither DNS system is able to exploit you.

Trust and domain ownership validation

We’ve sort of drifted off into the weeds on a side topic. So I tried to pick it up in another thread over here rather than continue hijacking this thread.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.