edns esc blacklisted by google ?

[Vasil Mikhalenya]

Hi all,

is there any way to understand for what reason Google started ignoring our ecs compatibility. At least it looks like that.

There is a guideline published https://developers.google.com/speed/public-dns/docs/ecs even so it does not make things easy to troubleshoot.

dig d.gcdn.co @8.8.8.8 +subnet=92.223.34.51/24

Seems like the majority of 8.8.8.8' responses does not take ecs into account. Worth to mention that both our NSes are available over anycast.

92.223.100.100

92.223.100.200

Thanks a lot.

[Alex Dupuy]

Your name servers (including the alternate addresses 92.223.100.101 and 92.223.100.201 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 support.

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 supported ECS.

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.

[Vasil Mikhalenya]

Hi all,

Alex thanks for your reply.

Seems like the issue affects RU region mostly. Google Public DNS is making no-ECS requests towards our DNS servers located in Russia (it looks like the source is in Finland according to geo bases). Probably the issue is not related to our implementation. Any thoughts? Thanks in advance.

[Alex Dupuy]

Vasil wrote:

Seems like the issue affects RU region mostly. Google Public DNS is making no-ECS requests towards our DNS servers located in Russia (it looks like the source is in Finland according to geo bases). Probably the issue is not related to our implementation. Any thoughts? Thanks in advance.

I can confirm that our resolvers in Finland represent most of the ones that have been failing to auto-detect ECS support from your name servers.

Here are numbers of resolvers that are detecting ECS for each of your anycast IP addresses:

Latest release

group F (80 jobs) .100: 17  .101: 34  .200: 22  .201: 23

group R (110 jobs) .100: 9  .101: 10  .200: 11 .201: 6

Previous release

group G (110 jobs) .100: 6  .101: 8  .200: 2  .201: 8

group M (110 jobs) .100: 1  .101: 4  .200: 4  .201: 8

The few resolvers that do detect ECS are getting a strong signal, and are sending all of their queries with ECS.

Unfortunately, the queries to your authoritative name servers that are sent with ECS are anonymized in our logs in a way that removes your responses, so I can't tell how or why your name servers are failing to respond with ECS (and therefore causing our resolvers to stop sending ECS).

I wonder whether your name servers are returning truncated responses, either because of large response data, or because of rate limiting.

If you can capture some traffic and check, that might be a clue.

[Alex Dupuy]

Vasil wrote:

Seems like the issue affects RU region mostly. Google Public DNS is making no-ECS requests towards our DNS servers located in Russia (it looks like the source is in Finland according to geo bases). Probably the issue is not related to our implementation. Any thoughts? Thanks in advance.

I can confirm that our resolvers in Finland represent most of the ones that have been failing to auto-detect ECS support from your name servers.

Updated at https://issuetracker.google.com/issues/117266745#comment3.

TL;DR your authoritative servers are rate limiting our resolvers in Finland, which serve essentially all of the traffic from Russia. Once you stop rate limiting for the source address ranges of LPP IATA airport code in our locations published at https://developers.google.com/speed/public-dns/faq#locations you will get full ECS data.