When placing the order, you get a funny text string from the ACME provider. You need to create a TXT record that holds this value. How you create the TXT record is up to you and your DNS server – the ACME provider doesn’t care.

I don’t believe DNS-over-HTTPS is relevant in this context. AFAIK, it’s used by clients who want to query a DNS server, and not for an operator who wants to create a DNS record. (Please correct me if I’m wrong.)

▲ 0x0000000 2 days ago | parent [-]

The ACME provider makes a query to the DNS server to validate the record exists and contains the right "funny string". Parent's question was whether that query is/can be made via DoH.

▲ cpach 2 days ago | parent [-]

Perhaps I have poor imagination, but I fail to see why why it would matter?

▲ 0x0000000 2 days ago | parent [-]

Because nginx, as an HTTP server, could answer the query?

▲ Arrowmaster 2 days ago | parent | next [-]

You want to build a DNS server into nginx so you can respond to DoH query's for the domain you are hosting on that nginx server?

Let's ignore that DoH is a client oriented protocol and there's no same way to only run a DoH server without an underlying DNS server. How do you plan to get the first certificate so the query to the DoH server doesn't get rejected for invalid certificate?

▲ xg15 2 days ago | parent | prev [-]

At that point you might as well use the HTTP-01 challenge. I think the whole utility of DNS-01 is that you can use it if you don't want to expose the HTTP server to the internet.

▲ jcgl 2 days ago | parent [-]

No, that’s just one of the use-cases. Also:

- wildcard certs. DNS-01 is a strict requirement here. - certs for a service whose TLS is terminated by multiple servers (e.g. load balancers). DNS-01 is a practical requirement here because only one of the terminating servers would be able to respond during an HTTP or ALPN challenge.

▲ account42 2 days ago | parent | next [-]

> DNS-01 is a practical requirement here because only one of the terminating servers would be able to respond during an HTTP or ALPN challenge.

Reverse-proxying or otherwise forwarding requests for .well-known/acme-challenge/ to a single server should be just as easy to set up as DNS-01.

▲ jcgl 2 days ago | parent [-]

But then you have to redistribute the cert from that single server to all the others. Which, yes, can be done. But then you've gotta write that glue yourself. What's more, you've now chosen a special snowflake server on whom renewals depend.

In other words, no, it's not just as easy as setting up DNS-01. Different operational characteristics, and a need for bespoke glue code.

▲ xg15 2 days ago | parent [-]

> But then you have to redistribute the cert from that single server to all the others.

Wouldn't you have to do that anyway? Or is the idea that each server requests and renews a separate cert for itself? That sounds as if you'd have to watch out for multiple servers stepping on each other's toes during the DNS-01 challenge, if there is ever a situation where two or more servers want to renew their cert at the same time.

▲ cpach 2 days ago | parent [-]

Yup. There’s an RFC draft that addresses this dilemma.

https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account...

▲ jcgl 2 days ago | parent [-]

Afaiu, that's only a problem for trying to _delegate_ to multiple clients. But routine operation with multiple clients works just fine in my experience (doing multi-region load balancing). Multiple TXT records are created, I think (speaking off the top of my head).

▲ cpach a day ago | parent [-]

Ah! I stand corrected.

	▲	jcgl a day ago \| parent [-]
		I wanted to quickly double-check my (albeit limited) experience against docs. The RFC[0] implies the possibility of what I described (provided a well-behaved ACME client that doesn't clobber other TXT records): `2. Query for TXT records for the validation domain name 3. Verify that the contents of one of the TXT records match the digest value` And then the certbot docs[2] show how it's a well-behaved client that wouldn't clobber TXT records from concurrent instances: > You can have multiple TXT records in place for the same name. For instance, this might happen if you are validating a challenge for a wildcard and a non-wildcard certificate at the same time. However, you should make sure to clean up old TXT records, because if the response size gets too big Let’s Encrypt will start rejecting it. > ... > It works well even if you have multiple web servers. That bit about "multiple webservers" is a little ambiguous, but I think the preceding line indicates clearly enough how everything is supposed to work. [0] https://datatracker.ietf.org/doc/html/rfc8555#section-8.4 [1] https://letsencrypt.org/docs/challenge-types/#dns-01-challen...

▲ xg15 2 days ago | parent | prev [-]

Ah, that makes sense. Thanks!