Boulder: ACME DNS servers

[pauladams8]

Hi,

I wanted to know what DNS servers Let's Encrypt uses to validate the DNS-01 challenge. I read this forum post: https://community.letsencrypt.org/t/dns-servers-used-by-letsencrypt-for-challenges/32127/10 which says you use the authoritative nameservers, but this file https://github.com/letsencrypt/boulder/blob/master/cmd/boulder-va/main.go suggests that the DNS servers are pulled from a configuration file.

Also, https://letsencrypt.org/docs/challenge-types/#dns-01-challenge says

you can use CNAME records or NS records to delegate answering the challenge to other DNS zones

How does this work - do you make two DNS queries (one to the authoritative servers, then to the actual DNS server hosting the TXT record)?

I'm building a Let's Encrypt implementation for a hosting provider and was interested as I wasn't sure how best to validate the challenges on my end before requesting authorization from Let's Encrypt.

[cpu]

Hi @pauladams8

I wanted to know what DNS servers Let's Encrypt uses to validate the DNS-01 challenge.

I think you're asking whether we use a public caching recursive resolver like Google DNS, or Cloudflare DNS and the answer is that we don't. We run our own Unbound instances that resolve domains themselves by recursing from the root to authoritative nameservers.

We run a public Unbound instance for debugging that has a similar configuration to the production instances here: https://unboundtest.com/

I read this forum post: https://community.letsencrypt.org/t/dns-servers-used-by-letsencrypt-for-challenges/32127/10 which says you use the authoritative nameservers, but this file https://github.com/letsencrypt/boulder/blob/master/cmd/boulder-va/main.go suggests that the DNS servers are pulled from a configuration file.

Apologies, that answer of mine from 2017 isn't correct (:sweat:). I've updated it to hopefully make things clearer. The linked logic (as you note) picks from configured recursive resolver instances and isn't related to authoritative nameservers.

Each recursive resolver picks the authoritative nameserver that is queried from the set of delegated nameservers by some internal logic (I suspect it's random initially and then based on TTL/reliability subsequently but may be mistaken here).

How does this work - do you make two DNS queries (one to the authoritative servers, then to the actual DNS server hosting the TXT record)?

Essentially yes, if the DNS query for the _acme-challenge label made to the authoritative nameserver returns a CNAME we will use that canonical name for a subsequent TXT query and accept the value returned. All of this happens transparently within Unbound the same way other CNAMEs are handled during the process of making DNS queries.

As an analogy it's similar to an HTTP-01 challenge made to a domain receiving a 301 redirect to another webserver.

I'm building a Let's Encrypt implementation for a hosting provider and was interested as I wasn't sure how best to validate the challenges on my end before requesting authorization from Let's Encrypt.

You might find this blog post by @jsha helpful: https://letsencrypt.org/2019/10/09/onboarding-your-customers-with-lets-encrypt-and-acme.html It talks about using CNAME delegation for customer onboarding in some detail.

Depending on your scale it may make sense to try and run an Unbound instance with a matching configuration to Unboundtest and using it for pre-flight checks for onboarded domains.

Hope that helps!

[jsha]

You should also read our Integration Guide if you haven't already. One thing that trips up a lot of people and is only briefly touched on: Propagation and anycast.

Propagation is the process of a DNS record update being copied to all instances of the authoritative server. Sometimes this can take a while, and it can be hard to tell whether all instances of the authoritative server have a record, because doing a regular DNS query might return an answer from any one of them.

Anycast makes this even harder to tell for sure because there might only be 4 distinct IP addresses for the authoritative servers, but those might be served by hundreds of actually servers all around the world, all with different propagation delays.

[cpu]

I'm going to close this issue since the question was answered. Happy to continue the discussion on the community forum if you'd like. Thanks!

[pauladams8]

Thanks for the replies. I'll look at setting up an Unbound instance to match the test configuration.