Preface#
In the previous article, I wrote about configuring UpSteam DNS Server for Adguard Home, which requires selecting a DNS that supports ECS (EDNS Client Subnet) functionality. This article will guide you on how to actively detect whether a DNS supports ECS functionality and whether it is complete.
Testing#
Of course, when connecting to foreign DNS servers, I used foreign servers to make requests.
Here, let's assume:
- The domestic network number is 222.29.12.0/24, and the IP address is 222.29.12.23/32
- The foreign network number is 110.20.20.0/24, and the IP address is 110.20.20.23/32
The command used is as follows:
dig +nocl TXT o-o.myaddr.l.google.com @<dns server> +subnet=<your ip address> +short
Google DNS#
We all know that Google's DNS server is 8.8.8.8, so let's test it:
☁ ~ dig +nocl TXT o-o.myaddr.l.google.com @8.8.8.8 +subnet=222.29.12.23/32 +short
"172.253.237.3"
"edns0-client-subnet 222.29.12.0/24"
The first line of the response indicates the DNS server that sent the DNS information, and the second line indicates the ECS information we sent, which may be a network number or a specific IP address.
This kind of transmission information is quite good, as it transmits the network number of my current network, which can be considered as considering both ECS functionality and privacy requirements.
OpenDNS#
For OpenDNS, we can test 208.67.222.222:
☁ ~ dig +nocl TXT o-o.myaddr.l.google.com @208.67.222.222 +subnet=222.29.12.23/32 +short
"2620:0:cce::78"
"edns0-client-subnet 2620:0:cce::78/0"
As you can see, in the response information from OpenDNS, the DNS address and the transmitted ECS information are the same, so it can be concluded that OpenDNS uses the method of building a subnet replacement mapping table to protect user privacy.
When testing with a foreign IP address, the response information remains the same.
☁ ~ dig +nocl TXT o-o.myaddr.l.google.com @208.67.220.220 +subnet=110.20.20.23/32 +short
"2620:0:cce::77"
"edns0-client-subnet 2620:0:cce::77/0"
You may say that OpenDNS's ECS support is fake, but in fact, this is the result of OpenDNS using the method of building a subnet replacement mapping table. Of course, is this response information not as good as Ali DNS that uses the same method?
CloudFlare#
For CloudFlare, we can test 1.1.1.1 to observe the response when ECS functionality is not supported.
☁ ~ dig +nocl TXT o-o.myaddr.l.google.com @1.1.1.1 +subnet=110.20.20.23/32 +short
"172.71.209.45"
As you can see, only the DNS address of the response is printed, and no subnet information is printed. This is because CloudFlare promises not to collect user IP information, so naturally there is no ECS support.
Microsoft DNS#
The Microsoft DNS address is 4.2.2.2
☁ ~ dig +nocl TXT o-o.myaddr.l.google.com @4.2.2.2 +subnet=222.29.12.23/32 +short
"192.221.176.2"
It can be seen that it does not support ECS functionality.
dns.sb#
From the official website, its DNS address is 185.222.222.222
☁ ~ dig +nocl TXT o-o.myaddr.l.google.com @185.222.222.222 +subnet=110.20.20.23/32 +short
"2403:2c80:8888::2"
It can be seen that it does not support ECS functionality.
DNSPOD DNS#
This is a domestic DNS, which can be considered as Tencent DNS. Its DNS address is 119.29.29.29.
However, the behavior of this DNS is interesting. When the subnet information you send comes from a foreign IP address, it will send the network number according to the specification. But if the subnet information you send comes from a domestic IP address, it will not send according to the specification and will send the user's IP address. Here, the IP address I sent will be forcibly changed to 222.29.12.1/32.
Using a domestic IP address to make a request:
dig +nocl TXT o-o.myaddr.l.google.com @119.29.29.29 +subnet=222.29.12.23/32 +short
"edns0-client-subnet 222.29.12.23/32"
"60.29.229.99"
➜ ~ dig +nocl TXT o-o.myaddr.l.google.com @119.29.29.29 +short
"192.144.210.111"
This behavior is strange. When using the preset IP to make a request, it will return a /32 IP address. When not customizing the subnet information, ECS support suddenly disappears. This is very puzzling. It can be seen that its ECS support is not complete.
Using a foreign preset IP address to make a request:
☁ ~ dig +nocl TXT o-o.myaddr.l.google.com @119.29.29.29 +subnet=110.20.20.23/32 +short
;; communications error to 119.29.29.29#53: timed out
"edns0-client-subnet 110.20.20.0/24"
"101.226.232.24"
As you can see, when making a request with a foreign IP address, it will execute according to the standard.
When making a request using a foreign server
timochan@timochan-cloud:~$ dig +nocl TXT o-o.myaddr.l.google.com @119.29.29.29 +short
; <<>> DiG 9.16.42-Debian <<>> +nocl TXT o-o.myaddr.l.google.com @119.29.29.29 +short
;; global options: +cmd
;; connection timed out; no servers could be reached
It directly blocks the connection to foreign servers.
Moreover, when I tested it, this DNS often timed out. It is hard to imagine that this is a DNS service launched by a domestic large enterprise.
Ali DNS#
Ali's DNS is 223.5.5.5, which is an easy-to-remember address.
Using a domestic IP for the request:
☁ ~ dig +nocl TXT o-o.myaddr.l.google.com @223.5.5.5 +subnet=222.29.12.23/32 +short
"60.205.226.65"
"edns0-client-subnet 42.83.199.0/25"
As you can see, the transmitted subnet information is completely incorrect and different from the IP address I sent!! But the IP address attribution and the example are the same, so it uses the method of building a subnet replacement mapping table to protect user privacy.
Using a foreign IP address for the query:
☁ ~ dig +nocl TXT o-o.myaddr.l.google.com @223.5.5.5 +subnet=110.20.20.23/32 +short
"60.205.209.221"
"edns0-client-subnet 1.0.0.0/25"
As you can see, according to the mapping table, the transmitted ECS information is correct because it is the same as the example IP address.
Using address blocks like /25 does not seem to value user privacy, but in fact, it has almost nothing to do with the user's real IP address.
114 DNS#
This is also a well-known DNS server in China, with an IP address of 114.114.114.114. It claims to protect against advertising infringement, protect user privacy, and provide a green Internet environment.
Testing with a domestic IP address:
☁ ~ dig +nocl TXT o-o.myaddr.l.google.com @114.114.114.114 +subnet=222.29.12.23/32 +short
"60.215.138.229"
It can be seen that it does not support ECS functionality.
Baidu DNS#
Baidu DNS has an address of 180.76.76.76.
Testing with a domestic IP address:
☁ ~ dig +nocl TXT o-o.myaddr.l.google.com @180.76.76.76 +subnet=222.29.12.23/32 +short
"2400:a980:db::dec7:bf06"
Conclusion#
Through the previous tests, we know that some DNS servers seem to pay less attention to user privacy and use address blocks like /32, which makes it easy to guess the user's IP address. On the other hand, some more sophisticated DNS servers use the method of building a subnet replacement mapping table to freely limit the range of address blocks. This is because the actual destination is almost completely different from the user's real IP address, and they are only the same in terms of attribution. And the behavior of DNSPOD is inconsistent between domestic and foreign users, which is not the behavior that a public service should have. It treats users from its own country differently, while Ali, another Chinese company, does not do this.
Therefore, in China, I can only praise Ali DNS because it has complete support for DoT/DoH/H3/DoQ, complete ECS functionality, and uses a more powerful method of building a subnet replacement mapping table to protect user privacy. As a public DNS, if it were not for the current policies in China, I believe it would have greater development prospects outside of China. Of course, under the current policies in China, it is still a top-notch public DNS server in China. Naturally, DNSPOD DNS (Tencent) can only serve as a background for Ali DNS.
This article is synchronized and updated to xLog by Mix Space
The original link is https://www.timochan.cn/posts/study/check_dns_ecs_support