DNS Extension Edns-Client-Subnet

NS1 supports the edns-client-subnet (ECS) DNS extension. Read more about this feature in this article.

What is edns-client-subnet?

ECS is a DNS extension proposed in 2011 by a group of DNS and CDN operators. ECS-enabled DNS resolvers, when sending DNS queries to authoritative DNS servers like NS1's, may send along a portion of the IP address of the end user. Most commonly, they send along the first three octets of a (four-octet) IPv4 address, telling us, for example, that the request was initiated by a user with an IP address like 1.2.3.x.

This kind of information is useful because we can leverage it to make better routing decisions. For example, you may have a record with a Filter Chain including our GEOTARGET_COUNTRY filter. Without ECS data, we do geotargeting by looking at the geolocation of the IP from which we received the query -- usually, the user's resolver -- which may be different from the geolocation of the actual end user. The theory is that most of the time, users are nearby their resolvers, and in general, this is true.

Public resolver networks like Google Public DNS and OpenDNS may render this assumption incorrect because users may be routed to a resolver that's relatively distant from them, geographically and topologically. But if those public resolver networks send along ECS data, we can use that data to determine the network of the requester and their geolocation, dramatically improving the accuracy of our routing for users of public resolvers.

There are more details about how the ECS extension works and why it's important at the Global Internet Speedup website.

What is the impact of edns-client-subnet on query counts?

There's a downside to edns-client-subnet: when we compute an answer with the Filter Chain for a DNS query using ECS data, the answer is only valid for users in a specific "scope" -- in other words, users in the same network as the requester whose ECS data was sent to us. If the resolver needs to answer a query for someone in a different network, it needs to ask us again -- and send along ECS data for the new user's network. So, using ECS can result in quite a few more queries than sticking with per-resolver routing.

How many more queries? It's tough to say because it depends on a number of factors, from how many of your users leverage Google Public DNS and OpenDNS, to how topologically and geographically distributed they are.

For a non-ECS enabled record, we typically see 2-3% of queries coming from Google and OpenDNS. For an ECS-enabled record, that can inflate to between 10-50% of queries depending on your user base, and in some extreme cases we've seen traffic to a record inflate 2 to 3 times upon enabling ECS.


Using edns-client-subnet with NS1

Since ECS can result in increased query counts, NS1 allows you to choose, on a per-record basis, whether or not to use ECS data when available. To enable or disable use of edns-client-subnet, simply toggle the button under "Enable Client Subnet" on any advanced record page. ECS is enabled by default, which is indicated by the appearance of a pink button. Click the button and hit Save to disable ECS.

Among our current filter algorithms, ECS data is leveraged by: GEOFENCE_COUNTRY, GEOFENCE_REGIONAL, GEOTARGET_COUNTRY, GEOTARGET_LATLONG, GEOTARGET_REGIONAL, NETFENCE_ASN, NETFENCE_PREFIX, STICKY, STICKY_REGION, and WEIGHTED_STICKY.

Static DNS records do not leverage ECS -- there's no decision to be made about which answer to return -- but records with a Filter Chain may be able to use ECS data. If edns-client-subnet is enabled for a DNS record, and the record's Filter Chain includes one of the filters that can leverage ECS data, then we'll use ECS and take care of the rest. If you disable ECS then all our filters will use the resolver's IP address in their computations, even if we get ECS data from the resolver.