Alex Dupuy <alexdupuy AT google.com>: Oct 10 08:15AM -0700
Your name servers (including the alternate addresses 220.127.116.11 and
18.104.22.168 that you omitted) appear to be returning /16 scope
prefix-length on all queries, which might not be optimal for IPv6 clients,
since the first 16 bits of an IPv6 address usually do not provide any
consistent geographical location (typically 32 or even 48 bits are needed
for accurate geo-location).
It can take a while for the auto-detection feature of Google Public DNS to
recognize ECS support from name servers that did not previously support it,
since we will only send ECS once every thousand queries when we detect no
We are currently showing that a few more than 450 of our resolvers (in
virtually all of our data center locations, except in Finland) are still
sending only that minimal level of ECS to your anycast name server IPv4
addresses. While this is only a bit more than 5% of our resolvers, as the
first guideline points out, even just a few name servers that do not
support ECS will be responsible for the vast majority of cached data.
Recognizing support for ECS would be much faster if you had followed the
eighth guideline, and used new IP addresses for the name servers that
For what it is worth, when I run the query you suggested in New York, I am
getting ECS scoped responses from Google Public DNS for your domain.
If your ECS support is not new, and this is not just a slow process of
recognizing support, I would say the most likely guideline that you are not
following is that you are not sending ECS for some domains that are
delegated to the name server addresses you have indicated.
Otherwise, some time will probably fix all the problems.