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
