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 8.8.8.8.
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:
6 Likes
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?
4 Likes
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.
6 Likes
6 Likes
Thank you very much. Currently, there are no further questions regarding this matter.
2 Likes
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?
2 Likes
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.
6 Likes
We have changed edns-buffer-size to 1232
6 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.