Shouldn't verification via DNS record be a priority?

looks promising :slight_smile:


Yeah, that does look promising… Definitely hope to see this in place as it will enable me to easily set up a gateway server that all of my internal developers can use to request certificates for hidden/on-premise servers - without those servers being made available for external connections.


I support MaxGashkov’s request as well.

I work for a registrar and we manage many customers DNS from our Nameservers, adding a TXT record is the most straightforward form of validation for us.

In the ACME spec, Section 7 , it states,

A CA may choose different sets of challenges depending on whether it has interacted with a domain before, and how. For example:

  • New domain with no known certificates: Domain Validation (DVSNI or Simple HTTP)

are there any reasons other than what @riking has provided in this thread for not doing DNS validation via TXT record the first time the CA sees a new domain name?

1 Like

Add “development time” to what I said above; plus it’s better to support one configuration & get it working and ironed out, then expand to others.

1 Like

Mainly this, we’d rather be much more confident with our original challenge types and the rest of the issuancce infrastructure than rushing to add a new feature (and fixing all the bugs that come along with that process).

Do you have a rough idea of what additional development will be required? Is this something where significant work has to be done, or are there just a few small missing pieces? Main reason I ask is that supporting pure-DNS validation opens up a whole range of use cases for LetsEncrypt certificates for internal servers that couldn’t ever reasonably be made directly accessible - but their names could trivially be made visible to public dns.

Obviously this is isn’t the primary use case - but I think you’ll find that there will be large numbers of people that would make use of these certificates for internal services that wouldn’t otherwise be able to use them - for internal test servers, networking infrastructure, management endpoints, etc.

In my case, I’d set up a special intermediate server that internal authenticated users could use - and would have that server perform all the interactions with LE, including updating DNS for validations.


@nneul: Much of the code has been written, but we are really sharpening our focus to make sure we hit our launch dates with the very best code, which is why we’re not launching with support for DNS-based challenges. We agree it’s extremely useful, especially for hosting providers, and are going to try and launch it sometime not long after launch of the overall service.


@jsha Suggestion to consider that would be much simpler - and much narrower code path change - but would allow for the same level of functionality for hosting providers/private networks/etc as DNS based validation:

Keep using the Simple HTTP based validation, but instead of JUST connecting to IP(domain), add the capability to do a SRV record lookup to determine the ip/hostname to connect to.


_letsencrypt-acme-http.<domain>. IN SRV 10 2 80
_letsencrypt-acme-https.<domain>. IN SRV 10 2 443

That would allow for the scenarios of having a dmz or alternate host to manage the acme enrollment - but still in a mostly automated fashion. Would also allow for the scenarios that many have brought up for cases where they can’t run the ACME software on the actual host - such as when there is a cluster of servers hosting the domain - or for users that have AWS/CloudFront/etc. sitting in front making it more difficult to do the fully automated request.

To me, this would require only very minimal changes to the validation code - to do the additional optional DNS lookup to control what host is connected to for the validation. The rest of the Simple HTTP validation logic could stay exactly the same.

A slight variation of this would be:

_letsencrypt-acme-proxy.<domain>. IN SRV 10 2 80

which would be a bit more complicated to implement - since you’d have to be aware of proxy protocol/CONNECT/etc. depending on what URLs you passed through.


Not to repeat what others have said, but similar to konklone’s point, this would make appengine and other such services easy, whereas right now manual method involves major edits to static file serving configs.

if we ycould get the ability to change the port using that SRV I am all into it, I could tell it to use some port I dont really use and then forward that to my raspi. while my PC doesnt care at all about anything

It seems that the dns-01 challenge is currently not offered by the server running at: even though the implementation is already in boulder. Is there already a timeline for when this authorization method will be available?

What is not exactly clear is whether the authorization of a domain through a dns-01 challenge does imply the authorization of all hosts (excluding sub domains) under this domain, possibly even for host names which do not (yet) have a DNS record?



I’m also very interested in DNS validation (or DNS SRV records), is there any news on this ?

1 Like

@Euclid in that case they could also issue wildcards.

Any news on where this might sit on the priorities list now that you’re in public beta?


It’s very high on our priorities list now. :slight_smile:


that’s nice then I will be able to get my certs soo without hassle coz doing manual over SSH (windows PC with XAMPP, nothing supporting that) from my raspi for like 14 domains is annoying, I rather just bind a has of my public key or whatever to it.

[quote=“jsha, post:23, topic:604”]
It’s very high on our priorities list now. :smile:
[/quote]that is awesome news :sunglasses:

1 Like

it truly is. also if possible try to make it a static identifier liked to the account so as long as I dont take the record out that I can get my certs, also include subdomains please.

You might want to think this through. It’s a horrible idea in the form you are suggesting.

why that?
it’s not as if someone can inject their account keys into my DNS.