Shouldn't verification via DNS record be a priority?

+1, need this badly.

making an API call to route53 to create an SRV or TXT record is much easier than file based auth.

5 Likes

:+1: here, too. Would strongly prefer to authenticate via DNS.

Excellent, it’s so much more convenient than uploading files to the webserver. Hope this gets released soon!!

+1 Looking forward to the release of this functionality as this method would be far easier for us using Route53

i would prefer dns validation, also.

I too would like to see some sort of dns option soon
especially if it allowed for cname following
(as atm placing files in all cluster members for all domains that are clustered under the san cert aint easy)

the cname following would just be nice plus for us as hosted websites are done via us or them cnaming www.whatever at the cluster (as some people hosting with us want their dns to stay with them)

and if auth could also be telling them to point a cname at a location in our zone we can put the tokens to show we admin the san-certs/clusters etc it would be sweet

as currently we only provide http to clustered customers as organising a san cert to cover so many domains cost effectively is a no-go (as most of our customers are charity/non-profits and have no real case for spending on https, but we’d like to offer it as default if we could get SANs working effectivly

Reminder: per our Community Guidelines, don’t post +1’s to indicate you agree, since it makes it harder to see posts with new info. Instead, please like (:heart:) the first post in this thread. Thanks!

1 Like

I’m looking at the case(s) where I want to use (non-HTTPS) certificate(s), and again having problem(s) with the HTTP file “dump” as these services are behind NATting firewall(s) and then to attempt to get HTTP (which is already NATted elsewhere) to the specific server without a different port (and upnp etc.) is close to impossible, so that is why I am also looking at a DNS authentication method, and I’m typically using at CloudFlare (which doesn’t do SSL certificates for my email/etc. :open_mouth: ) as the method to automate the DNS entries to be added.

Is there some kind of roadmap where progress on this highly anticipated feature can be tracked? Since it looks as if only Boulder needs some features added before we can start using it :slightly_smiling:

7 Likes

I’m looking forward to this too. All of my HTTP websites are just redirects to my HTTPS sites and having to open up an actual HTTP website just to do the cert upgrade every 90 days in a pain.

you dont even have to open an HTTP site. the http-01 already accepts redirects, so if you keep the path and stuff while redirecting then it should work without a problem.

DNS-01 is enabled in production. https://twitter.com/letsencrypt/status/689919523164721152

4 Likes

Cool! How does it work? I can’t find documentation anywhere.

Thanks so much for this. I was able to get it working a few hours ago.

The protocol specification is in ACME: https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-7.5

There are a few clients that support it already. letsencrypt.sh is one I know of.

Ah, OK. So the letsencrypt-auto clients doesn’t support it yet. Thanks.

Just be aware the server support is broken currently for a few DNS providers (cloudflare, google domains, and dnsimple I believe are all affected). Hopefully new build of server code will make it to production soon.

Why or how is it broken? Doesn’t DNS work the same way regardless of who provides it?

1 Like

If I understand correctly, there is an internal check done (at Boulder) that the DNS they check as the authoritative server is really the authoritative DNS server for that domain. Some ( such as those listed) return a null response - even though they are the authoritative server. Hence the request “fails an internal sanity check”

I’ve successfully completed a DNS verification with Google Domains, FYI (back when it was on staging)