Introducing EDNS-Client-Subnet (ECS)

EDNS-Client-Subnet (ECS) is a draft informational RFC that uses the EDNS0 extensions to the DNS. Recursive DNS services that support ECS can provide the client (end-user) subnet as part of the DNS query, allowing authoritative DNS providers to use this extra information to make more informed traffic routing decisions.

Dyn released ECS support for Traffic Director in early September 2015.

FAQ of Dyn’s ECS Implementation

Q. What is the basis of Dyn’s ECS implementation?

Dyn’s implementation is based off of the latest EDNS-Client-Subnet informational RFC draft as of this writing (mid September 2015).

Q. Which Dyn customers have access to ECS?

Dyn customers who is using our Traffic Director service can enable and take advantage of ECS.

Q. How can I enable ECS on Traffic Director?

ECS is disabled by default. To enable this feature, please contact our helpful Technical Support team to assist you. When you contact them, please have a list of Traffic Director zones where you want ECS enabled ready to provide to the team.

Once the ECS option is enabled on each zone, it should propagate across the edge shortly. Once propagated, any Traffic Director instance with ECS implemented should begin taking advantage of ECS-enabled DNS Queries.

Q. Which Recursive DNS providers include ECS information in DNS queries?

As of this writing, the only known recursive DNS providers who include ECS information in DNS queries are:

Google Public DNS
OpenDNS

Google Public DNS and OpenDNS comprise of ~20% of worldwide DNS traffic according to some reports.

Q. What happens when a DNS query is received without ECS information?

DNS queries without ECS information will be processed the same way they are today. This is the more likely scenario since the majority of recursive DNS servers today do not provide ECS information.

Q. What happens when a DNS query for a Traffic Director instance is received with ECS information?

When a DNS query is received by our nameservers, we analyze the query in order to determine what response we provide. During this analysis, we will notice if ECS information is provided and whether a Traffic Director service will be involved in the response. If both is the case, we will use the ECS information for our geolocation lookup instead of the source IP address.

Once a geolocation is found and a response is selected, Traffic Director will provide a DNS response back to the source IP address. As part of this response we will include information via ECS regarding what subnet the response should be cached for.

For example, if a DNS query includes ECS information for 192.168.1.0/24 and the response uses Traffic Director, a response could request that it be stored for the 192.168.1.0/24 subnet in the cache. If 192.168.1.0/24 is actually part of a larger /20 block, Traffic Director could respond back with instructions to cache the response for 192.168.1.0/20. If it turns out we have no special response that requires per subnet caching, we would return a /0 so it is cached for everyone.

The recursive DNS server will then cache that response for the appropriate subnet and respond with that cached response for any client that falls within that subnet.

Q. What happens if a DNS query is received with ECS information and on a zone that has ECS activated, but no Traffic Director instance is involved?

We will notice that the DNS query is for a record that doesn’t use Traffic Director and return a DNS response that tells the recursive to cache the response for everyone (specifically, that the subnet is a /0).

Q. What is the cost of enabling ECS?

There is no direct fee for enabling ECS. However, enabling ECS will likely increase the QPS (Queries Per Second) sometimes significantly, on Traffic Director zone(s) where ECS is enabled. This is due to the increased queries from supporting recursives as their caches are less useful.

Depending on your current QPS usage, this could result in additional overage charges. Please contact your Account Manager with any questions.

NOTE:  The QPS increase should only be seen on records within Traffic Director instances. Any non-Traffic Director records should not see a QPS increase.