NS1’s platform is fully edns0-client-subnet (ECS) enabled. This means Google Public DNS, OpenDNS, and other ECS-enabled resolvers will send along details about the user doing a DNS query, which we can then use to improve the routing process by leveraging the data in your NS1 Filter Chains.
Not only are the NS1 platform and all our filter algorithms ECS-enabled, but we’ve gone a step further: we let you choose which of your records should use ECS data when it’s available. For example, you can choose not to use ECS data when you’re doing very coarse geotargeting (say, between a server in Asia and a server in Europe), and in exchange, keep your query counts down.
Let’s step back for a moment and review exactly how ECS works. 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 address that sent 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 incorrectly because users may be routed to a resolver that’s relatively distant from them, geographically and topologically. 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.
No free lunch
There’s a downside to ECS: 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 use 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-3 times upon enabling ECS.
Using edns0-client-subnet with NS1
Because ECS can result in increased query counts, we decided to give our customers a choice, on a per-record basis, whether or not to use ECS data when available.
No static DNS records 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 “Enable Client Subnet” is switched on for a DNS record as it is in the above graphic, 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.
Among our current filter algorithms, ECS data is leveraged by the following filters:
If you disable “Enable Client Subnet” for a zone, then all the filters will use the resolver’s IP address in their computations, even if we get ECS data from the resolver.