Setting Up an Anti-Pollution DNS

[Note: This article is outdated because many authoritative DNS servers have multiple IP addresses for both domestic and international users. They resolve based on the user’s public IP, so simply distinguishing between domestic and international websites using authoritative DNS server IPs is no longer practical. It is recommended to read the new solution in “Setting Up a Local Anti-Pollution DNS for Intelligent Domestic and International Website Traffic”.]

DNS service is a crucial foundational service of the internet, but its importance is often underestimated. For example, in August 2013, the .cn root domain servers were attacked by DDoS, causing .cn domains to be inaccessible. On January 21, 2014, the root domain servers were polluted by a famous firewall, causing all international domains to be inaccessible. Many internationally renowned websites are inaccessible in mainland China partly due to DNS pollution, which returns incorrect IP addresses for domain names.

Setting up an anti-pollution DNS is not as simple as using a VPN to resolve all domain names. There are mainly two issues:

Why Differentiate Between Domestic and International Resolution

Some large websites often have telecom IPs for telecom queries, educational network IPs for educational network queries, and international IPs for international queries. DNS servers provide different responses based on the source IP of the DNS query. The most famous bind9 software for authoritative DNS servers has a “view” feature that allows different DNS requesters to see different views.

Large websites generally use content delivery networks (CDNs) to distribute static content to servers worldwide. They also use enterprise-level virtual private networks (VPNs) to handle content that cannot be statically distributed, using distributed databases or fast routing to central nodes. Regardless of how the website is implemented internally, accessing the nearest IP on the network is generally best for users.

If you use an international VPN to resolve all domain names, whether directly using the recursive DNS resolution service provided by the VPN’s operator or setting up your own recursive DNS server like bind9, the authoritative DNS server of the website will see the request source as an international IP. It will either return an international IP or the domestic IP that the website considers fastest for international access. For example, querying mirrors.ustc.edu.cn from abroad returns China Mobile’s 202.141.176.110. But if I am an educational network user, accessing this IP might be slow due to the well-known poor interconnectivity between domestic operators.

How can we prevent DNS pollution while ensuring domestic websites resolve to the IPs of their respective operators? We observe the recursive query process of example.com from the root server (illustration):

1. The root server tells that .com is managed by x.gtld-servers.net, and this step does not involve regional resolution.

2. x.gtld-servers.net tells that example.com is managed by dns.example.net, and this step does not involve regional resolution.

3. The IP of dns.example.net is found, omitted here.

4. dns.example.net tells the IP address of example.com, and this step involves regional resolution.

In other words, if example.com is domestic, we only need to use a domestic IP when sending DNS queries to dns.example.net. Generally, the DNS servers of domestic websites are also domestic, so as long as all DNS requests to domestic IPs go through the operator’s line instead of the VPN, domestic websites can resolve to the IPs of their respective operators. Of course, for domestic websites using CDN services provided by international CDN providers (such as Amazon, Edgecast), the above assumption may not hold, as these international CDN providers’ DNS servers are generally abroad. I haven’t thought of a good way to solve this problem.

Will this approach still lead to some domains being polluted? I don’t think so. If a domain’s DNS is domestic, there’s no need for a certain firewall; simply ordering to stop the domain’s resolution will suffice. Therefore, the authoritative DNS servers of polluted domains should all be abroad. Since only domestic IPs go through the operator’s line, these DNS queries should all go through the VPN and should not be polluted.

Implementation of Domestic and International Resolution Differentiation

To let domestic IPs go through the operator’s line and other IPs go through the VPN, simply modify the routing table. To generate a CIDR format list of domestic IPs, you can download the public IP address allocation data for mainland China from APNIC and perform simple string processing:

1
2
3
4
5
6

#!/bin/bash
tmp=$(mktemp)
wget -4 http://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest -O $tmp
cat $tmp | awk '{FS="|"}{if($2=="CN" && $3=="ipv6"){print $4 "/" $5}}' >chnroutes-v6.txt
cat $tmp | awk '{FS="|"}{if($2=="CN" && $3=="ipv4"){print $4 "/" (32-log($5)/log(2))}}' >chnroutes.txt
rm -f $tmp

Setting up the route is also straightforward:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#!/bin/bash
IPV4_GATEWAY=   # 运营商给的网关 IP
IPV6_GATEWAY=
IPV4_VPN=       # VPN 的网关 IP，如 10.8.0.1
IPV6_VPN=
IPV4_LOCAL=     # 自己的公网 IP
IPV6_LOCAL=
# 上面这部分是要自己填写的

ip route flush table 1000
cat chnroutes.txt | while read prefix comment; do
    if [[ "$prefix" =~ ^[0-9.]+(/[0-9]+)?$ ]]; then
        ip route add $prefix via $IPV4_GATEWAY table 1000
    fi
done
ip rule add from all lookup 1000
ip route replace default via $IPV4_GATEWAY table 1001
ip rule add from $IPV4_LOCAL lookup 1001 # 这是为了保证进来的连接仍然从公网出去而不要走 VPN
ip route replace default via $IPV4_VPN  # 如果 VPN 已经设置了默认路由，就不用这条，如 OpenVPN

ip -6 route flush table 1000
cat chnroutes-v6.txt | while read prefix comment; do
    ip -6 route add $prefix via $IPV6_GATEWAY table 1000
done
ip -6 rule add from all lookup 1000
ip -6 route add default via $IPV6_GATEWAY table 1001
ip -6 rule add from $IPV6_LOCAL lookup 1001 # 这是为了保证进来的连接仍然从公网出去而不要走 VPN
# 注意，下面两行要根据你的情况选一行
ip -6 route add 2000::/3 via $IPV6_VPN            # 如果你的 VPN 支持 IPv6 且没有设置默认路由
ip -6 route add unreachable 2000::/3 table 1000   # 如果你的 VPN 不支持 IPv6

If your network does not support IPv6 at all, simply ignore the above IPv6 configuration. If your operator’s network supports IPv6 but the VPN does not, be sure to actively block foreign IPv6, or else domain names resolved through IPv6 might be polluted. By the way, if you don’t want to use IPv6 to resolve domain names, you can add -4 to the bind9 command line parameters. In the Debian system, you can modify /etc/default/bind9, changing OPTIONS=”-u bind” to OPTIONS=”-u bind -4”.

It is recommended to use bind9 to set up a recursive DNS server. Be sure to modify /etc/bind/named.conf.options (this is the path under Debian), comment out all the forwarders braces, and do not use others’ recursive DNS services, relying entirely on yourself to resolve step by step from the root. The default configuration of bind9 does not allow external networks to use this recursive DNS server, which is great if you use it yourself. If you want to allow others to use it, you need to modify the settings for allow-query and allow-recursion.

Using Load Balancing to Improve VPN Stability

A single VPN connection may experience intermittent packet loss and can be blocked at any time. For example, the response time of DNS requests for an anti-pollution DNS set up using the above method within a day is shown in the figure below (all queries are for a certain international domain, and no DNS cache was used during testing). 2.3% of DNS query requests failed.

Capture

Capture

As shown in the figure above, DNS query failures (due to VPN packet loss or intermittent blocking) are evenly distributed throughout the day and can almost be considered random events.

When setting up a web server, we all know that to improve availability, multiple backend servers are set up, and the front end is just a proxy for load balancing. Why can’t DNS be like this?

I tried setting up three virtual machines. The first virtual machine binds to a public IP and provides DNS resolution services. The other two virtual machines only have internal IPs (allocated by the virtual machine management tool) and access the public network through SNAT. Virtual machine 2 and virtual machine 3 each connect to a different VPN, so the failures of the two VPNs can be considered independent.

In virtual machine 1, configure bind9’s /etc/bind/named.conf.options, using virtual machine 2 and virtual machine 3 as backends, and specify that this bind9 does not resolve domain names itself (otherwise, when both backends fail to resolve, bind9 will try to resolve itself, possibly getting a polluted IP).

1
2
3

forwarders { $VM2_IP; $VM3_IP; };

forward only;

In virtual machine 2 and virtual machine 3, deploy bind9 according to the above method and start the VPN. Don’t forget the settings for allow-query and allow-recursion.

Effect of load balancing:

(Due to different measurement methods, please do not directly compare the numbers in the figure below with those before load balancing, so the two curves before and after load balancing are not drawn on the same graph. The average response time should be reduced to half of the original, not as exaggerated as in the figure. Mainly look at the trend of the curve, with extreme values greatly reduced.)

Capture

Capture1

Of course, if both of your VPNs are unstable, you can add a third, fourth… This load balancing method is universal.

If any readers have better methods for setting up an anti-pollution DNS or question some of the practices in this article, feel free to discuss.