About the EDNS Client Subnet (ECS) DNS extension

ECS is a DNS extension proposed in 2011 by a group of DNS and CDN operators. It allows recursive resolvers, if they are willing, to forward details about the origin network from which a query is coming when talking to other name servers.

When sending DNS queries to authoritative DNS servers (like NS1's), ECS-enabled DNS resolvers may send a portion of the IP address of the end-user. Often, they return 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 information is useful because it can be leveraged to make better routing decisions. For example, you may have a record with a Filter Chain, such as NS1's Geotarget Country filter. Without ECS data, geo-targeting is done by looking at the geo-location of the IP from which the query was received. This is usually the end-user's resolver which may be different from the geolocation of the actual end-user. The theory is that most of the time when users are nearby their resolvers this is generally true.

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

For more information about the ECS extension, visit the Global Internet Speedup website.

There are disadvantages to the EDNS Client Subnet (ECS) extension: When NS1 uses ECS data to compute an answer to a DNS query with the Filter Chain, the answer is only valid for users in a specific scope (in other words, users in the same network as the requester). If the resolver needs to answer a query for someone in a different network, it needs to query NS1 again, and then send along ECS data for the new user's network. In short, using ECS can result in a higher number of queries than would occur with per-resolver routing.

How many more queries? It's hard to say as it depends on several factors — from how many of your users leverage Google Public DNS and OpenDNS, to how geographically-distributed they are.

Typically, for a non-ECS-enabled record, 2-3% of queries come from Google and OpenDNS. For an ECS-enabled record, that can increase to between 10-50% of queries depending on the user base. In some extreme cases, NS1 has seen traffic inflate up to 2-3 times upon enabling ECS.

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 ECS within a zone, navigate (drill-down) to the record-level settings. In the Filter Chain sidebar on the left side of the screen, there is an option to enable or disable ECS. Toggle the slider according to your preferences.

You can also enable or disable this function when creating a new filter chain.

Among NS1's 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 as there's no decision to be made about which answer to return — however, records with a Filter Chain may be able to use ECS data.