DNS systems use plaintext UDP protocol to communicate by default, so the content of users’ queries can be easily monitored, and the resolution results returned by servers can be easily tampered with. To solve this problem, technologies such as DNS over HTTPS/TLS/QUIC have been introduced in the hope of transmitting DNS queries in an encrypted manner. However, with the use of public DoH recursive resolution servers, authoritative DNS servers can only get the address of the recursive resolution server, but not the user’s address. So the intelligent resolution of geographic locations would not work. To solve this problem, the EDNS Client Subnet (ECS) protocol, also known as RFC7871, was developed. This article briefly describes how ECS works and how it works.
We use operators’ recursive servers every day, and they are geographically close to users’ machines, so they won’t cause big problems. However, if Chinese users use US DNS over HTTPS service, the resolved IPs may be US IPs, which will seriously affect users’ access.
I didn’t know the ECS protocol before. At that time, we could only use domain whitelist to solve this problem. Simply put, we configure dnsmasq on the router to do recursive resolution. dnsmasq supports setting different DNS resolution servers according to the domain prefix, for example, the following is a configuration for Apple.
|
|
dnsmasq will query the DNS records of the domain apps.apple.com from 114.114.114.114, so it will be able to get the address of Apple’s CDN node in China, thus achieving the “acceleration” effect.
For this reason, netizens maintain the dnsmasq-china-list project, which basically adds domestic domains as well as Google’s and Apple’s domestic domains to the list.
This whitelist can only be described as a dumb solution. With ECS, we don’t need to maintain such a complicated whitelist.
ECS simply means exposing the user’s IP information to authoritative DNS servers. However, to protect user privacy, the recursive server does not send the user’s IP directly to the authoritative server. Instead, only the segment where the user’s IP is located is sent to the authoritative DNS server. If the client is using IPv4, then the network prefix sent is 24, and if it is IP6, then the network prefix is 56. Generally, the client addresses in the same network segment are located close to each other. The network segment here is called client subnet.
How ECS sends the client subnet is not detailed in this article, you can read RFC7871. Next, let’s take www.qq.com as an example to show the effect of using it.
Before using it, please make sure you can connect to Google Public DNS (8.8.8.8) directly.
I used a telecom network to look up the A record for www.qq.com.
This is the address of Tencent’s node in China. If I go to an overseas VPS and perform the same query:
This returns the akamai address in the US. If I add the ECS information.
We see that although the VPS is in a foreign country, it still returns a node in the country. That is to say, no matter where you perform the query, as long as the subnet remains the same, the node returned must be closer to you.
If you are using dnsmasq to perform DNS resolution, you need to add the following configuration.
ECS has a small disadvantage that the DNS cache of different subnets cannot be shared. This is easy to understand, because different network segments may correspond to different geographical locations, and the resolution results may be different, so naturally the cache cannot be shared. This may reduce the hit rate of the cache, but is not a big problem for scenarios like Google Public DNS, which has a high usage rate. announce/c/h4XLjnWvAp8).
With ECS, we only need to set up IP tunnels and IP diversions in China, and no longer need to engage in DNS resolution diversions.