Why does Let's Encrypt send a large number of DNS TCP requests to authoritative resolution

Why do a large number of DNS TCP requests be made to the authoritative domain name resolution service when using Let's Encrypt to automate certificate management? And it is a repeated request to change the case of the same domain name.

each of 5 secondary observing points are do its own authoritative DNS lookup and add first main point than now you see 6 set of request fore same domain

1 Like

Let's Encrypt must perform at least two kinds of checks during validation:

  • Checking domain control, via the HTTP-01, TLS-ALPN-01, or DNS-01 method, all of which require us to perform a DNS lookup; and
  • Checking CAA, which also requires at least one DNS lookup.

In addition, we perform these checks from multiple locations around the world, to help prevent BGP hijacking attacks.

Finally, we are required to operate our own recursive resolvers, and cannot rely on public cacheing recursive resolvers such as

Putting all of this together -- doing both kinds of checks, from multiple locations, directly -- means that we usually have to make 8+ DNS queries to your authoritative name servers.

You can read more about these here:


I think there is no problem with multiple queries, but why do we need to specify the TCP protocol for DNS querying? Using the UDP protocol can also achieve the same effect.

I believe that our DNS resolvers attempt UDP first by default and only fall back to TCP if they are receiving truncated (i.e. too large for the UDP max packet size) answers. Are your nameservers serving particularly large answers?


Isn't TCP mandatory according to the official DNS specs?

The server needs to support sending TCP, but clients can choose to use UDP.

If the Unboundtest config matches Let's Encrypt's production config (which it usually does), it sets edns-buffer-size: 512 which I believe will try UDP and then switch to TCP if over 512 bytes. (Which basically anything using DNSSEC will, though probably other responses can as well.)

There's an API announcement from Let's Encrypt from 2018 explaining the change as increasing resistance to DNS spoofing attacks.

As I understand it, it's much harder for an attacker to spoof TCP responses than UDP responses.

Is there some problem that your DNS servers are having with needing to handle multiple TCP responses? Generally I would expect DNS servers would be able to handle the scale of requests that Let's Encrypt is using, if they're going to be on the Internet in general.


Thank you very much. Currently, there are no further questions regarding this matter.


Thank you very much.
We support TCP, but its rate limit cannot be higher than UDP.

In addition,why set edns-buffer-size of 512 bytes,not 1232 bytes?

We have analyzed the response packets of most TCP requests, many of which are around 512(equal or less than).

Should TCP queries be used and determined based on the TC bit of the server's response, rather than the size of the response packet?


We have had the buffer size set to 512 for some time, when there was less clarity around what the optimal values are to avoid fragmentation attacks.

We will likely change the value to 1232 soon, as that’s a value the DNS-OARC now advises.


We have changed edns-buffer-size to 1232