EDNS Client-Subnet

The problem

A recursive DNS resolver such as Google Public DNS or your ISP's DNS server resolves domain names into IP addresses. Popular websites or services are usually hosted on Content Delivery Networks (CDN) where a domain name could resolve into different IP corresponding to servers in disperse locations. In such case, when a recursive DNS resolver queries the authoritative name server for a domain, it is provided with an IP address in close proximity to the recursive DNS resolver. The authoritative name server considers the source IP of the recursive DNS resolver in picking the optimal fit.

Everything is fine if an end-user machine initiating the original DNS query is also in close proximity to the recursive DNS resolver. Problems arise when the end-user machine makes a DNS query to a remote DNS server. This is more common than likely nowadays with the popularity of public DNS servers. From a remote DNS server, the end user does not get an IP address that's close by.

EDNS Client-Subnet

EDNS Client-Subnet (ECS) is one solution to the problem. It requires support from both the recursive and the authoritative name servers. The recursive DNS resolver takes an end-user machine's source IP subnet (hence client-subnet), sends it over to the authoritative name server inside the query record with EDNS0 extension. The authoritative DNS server takes the client-subnet into consideration when resolving a domain into IP address with optimal promixity to this client-subnet.

It's reported that Google Public DNS and OpenDNS support ECS (while Cloudflare Public DNS explicitly does not support ECS in the name of privacy). Authoritative name servers operated by major CDNs, including but not limited to Fastly, AWZ, Tencent, Cloudflare, COMODO and Google support ECS. For end users to benefit from EDNS Client-Subnet, the following conditions must be true: 1) an end user uses a remote DNS server (sufficiently far apart in between); 2) the remote DNS server supports ECS; 3) authoritative name servers support ECS.

You could test ECS with dig and its +subnet CLI option:

$ dig +subnet=161.202.17.0/24 @8.8.4.4 www.cnn.com

; <<>> DiG 9.11.5 <<>> +subnet=161.202.17.0/24 @8.8.4.4 www.cnn.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42307
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 161.202.17.0/24/0
;; QUESTION SECTION:
;www.cnn.com.			IN	A

;; ANSWER SECTION:
www.cnn.com.		205	IN	CNAME	turner-tls.map.fastly.net.
turner-tls.map.fastly.net. 22	IN	A	151.101.1.67
turner-tls.map.fastly.net. 22	IN	A	151.101.65.67
turner-tls.map.fastly.net. 22	IN	A	151.101.129.67
turner-tls.map.fastly.net. 22	IN	A	151.101.193.67

More likely than not, you won't see a difference if the domain (in this case www.cnn.com) is not optimized through DNS for geolocations (to be explained below). I would like to hear if you have discovered a domain name that will resolve to geographically different IP given client subnets are sufficiently dispersed.

Do You Need ECS or Not

The short answer, perhaps not.

The longer answer: most likely your internet experience won't be much different without ECS. Check the aforementioned three conditions again. In other words, if you're using your ISP's DNS server or one of public DNS servers sufficiently close by (e.g. in the same or nearby city or county), you gain no extra benefit with or without ECS. If an authoritative DNS server hosting a domain that you query doesn't support ECS, it's also end of the game.

In addition, there are other technologies that solve the same problem. One widespread technique is AnyCast in which a domain resolves to the same (or same set of) IP globally. For example, www.cnn.com shown above. End users are directed to the nearest server(s) at network layer through intelligent routing (aka BGP routing tables). Another technique is increasing points of presence of public DNS servers. That's how major public DNS operators such Cloudflare and Google have already done. Contrary to people's perception, your ISP's DNS server is perhaps the best server next to operating your own, assuming you have enough faith in their integrity and competence.

Last but not least, if you run your own recursive DNS resolver on LAN e.g. running Unbound in resolver mode, you won't need ECS as IP addresses recursively resolved should be of optimal proximity to you. That's one of the cool benefits of running your own resolver instead of forwarding to public DNS.

Aside - ECS in Unbound

You can compile Unbound with option --enable-subnet to include support for ECS. When enabled, Unbound will maintain a separate internal cache for domain queries resolved by authoritative name servers with support for client subnets, in addition to its regular cache for domains resolved without client subnets. You might only want to enable ECS in Unbound if it's serving friends in different towns or cities.

comments powered by Disqus