Google no longer returning AAAA records?

[Phil Mayers]

On 15/04/15 16:05, Brian Rak wrote:
> We noticed that we're no longer getting AAAA results back for google.com
> when we do queries from a few of our recursive servers (other ones are
> fine).
>
> A bit of searching revealed that a few of our servers are listed here
> http://www.google.com/intl/en_ALL/ipv6/statistics/data/no_aaaa.txt
> (there are 4 listed for AS20473, which are the ones I'm referring to)
>
> However, I can't seem to find any information about why we'd be listed
> there, nor can I find anything telling me how to get delisted.

Yes. They don't provide that info, nor do they provide a way to request 
a de-listing AFAIK.

You'll be removed automatically when "the problem" goes away.

There's a lot of discussion in the archives about this, but I believe 
that, as far as is known publicly:

  1. There's a web-bug in the google search page
  2. They correlate IPv6 failures of this against the DNS lookup
  3. When the DNS source IP hits a certain threshold of correlatd 
failures, they stop serving AAAA records for a time (one week?).

Subjectively it's irritating that Google don't provide info to operators 
as to the specifics of the cause, but look at it from their PoV - 
there's a lot of info, some of it potentially personal / data-protected, 
that they'd have to communicate securely to operators when they ask.

It would be a lot of work for them and I'm somewhat sympathetic on that 
basis (although I wasn't when it was happening to us ;o)

My guess: you've got some form of broken IPv6 connectivity talking to 
your resolvers; maybe rogue RAs, a tunnel, VPN, etc.

The customers with this problem aren't reporting it because Happy 
Eyeballs, but the Google web-bug is detecting it.

We saw a reduction (and eventual end to) our experiences of this when we 
finished our native dual-stack deployment *and* when we blacklisted 
serving of AAAA to some of our more troublesome netblocks - mainly 
remote access VPN users.

We monitor whether google are blacklisting us in our Nagios setup, so we 
can see if problems come back.

An alternative might be to steer different classes of users to different 
resolver query source IPs (either actual different resolvers, or using 
views & multiple IPs). Then, you can see which source IP and thus class 
of users is triggering it.

Good luck tracking it; it can be frustrating :o(

Cheers,
Phil