Google no longer returning AAAA records?

[Brian Rak]

On 4/15/2015 11:28 AM, Phil Mayers wrote:
> 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

Well, we're a hosting provider and we have a very large number of users 
doing all sorts of crazy things.  These particular resolvers are used by 
our low cost virtual server platform, so we see many users running a 
wide variety of proxy software.  It's pretty difficult to prevent people 
from breaking their IPv6 connectivity when they have full control over 
the machines.

There may be some things that we can do to reduce the number of broken 
IPv6 setups.. I just wasn't sure if we'd ever drop off that list 
automatically.