why 8.8.8.8 put IPV6 address in edns-client-subnet to query A record, not AAAA?

[whic...@gmail.com]

Hi googler,

It seems 8.8.8.8 apply a new strategy? we have some trouble since 2016-03-31.

our CDN ns receive many A query from 8.8.8.8 ,which carry ipv6 edns-client-subnet, In this case, why 8.8.8.8 don't use AAAA query instead of A query? this may cause ipv6 client query A record but can't get correct A response.

I‘m looking forward to your reply. 3Q~

[Alex Dupuy]

Many hosts and DNS forwarders are dual-stack these days, and have working addresses on both IPv4 and IPv6. These hosts typically implement a "Happy Eyeballs" algorithm and query for both A and AAAA records, connecting to both (if present), using the one that responds first and closing the other connection.

Since Google Public DNS offers both IPv4 and IPv6 addresses, dual-stack clients may use either or both DNS service addresses to resolve both A and AAAA type records. Because of this, it is perfectly normal and expected that EDNS Client Subnet (ECS) data may contain either IPv4 or IPv6 addresses, regardless of whether an A or AAAA or any other record type is used, or whether the authoritative server NS records have any A or AAAA records themselves, or whether Google Public DNS queries the authoritative server via IPv4 or IPv6.

Any authoritative nameserver (even if it is IPv4-only) that supports ECS at all must be prepared to handle both IPv4 and IPv6 addresses in ECS data; failure to do so correctly can cause sporadic NXDOMAIN / SERVFAIL for many Google Public DNS clients (even ones that are IPv4-only). This happened recently to a CDN; it took us a while to figure out that they were not handling IPv6 ECS data correctly and this caused periodic SERVFAIL for their hosted domains.

@alex

[whic...@gmail.com]

thank you for your reply,alex,

1. When did Google Public DNS use dual-stack ? 

2. if we don't wan't to use ipv6 recently,could you give some advices about how nameserver respond? how to handle IPv6 addresses in ECS data? don't response, or give nxdomain, or just return the only one response with all IPV6 addresses?

3. whether ipv6 cache affect ipv4 cache in 8.8.8.8 ? 

Thank you!

在 2016年4月6日星期三 UTC+8下午11:23:28，Alex Dupuy写道：

[Alexander Dupuy]

1. When did Google Public DNS use dual-stack ? 

 Since June 2011 at least (https://groups.google.com/forum/?hl=en&fromgroups#!topic/public-dns-announce/yCg-9A23L3g). That announcement is for the public IPv6 anycast addresses for receiving client queries; it is possible that Google Public DNS was querying authoritative servers via IPv6 even before that.

2. if we don't wan't to use ipv6 recently,could you give some advices about how nameserver respond? how to handle IPv6 addresses in ECS data? don't response, or give nxdomain, or just return the only one response with all IPV6 addresses?

Ideally you can use IPv6 GeoIP databases; although commercially available ones are typically not as extensive or accurate as for IPv4, they do exist. I believe that the free tier of the MaxMind GeoIP datasets and possibly the free tier of ipinfo.io support IPv6 lookups.

Even if your nameservers or other servers do not support IPv6, returning a CNAME or A record that will direct users to an IPv4 address in a nearby geographical region is probably a good idea.

If you have no ability to geo-locate IPv6 address at all, you should return a default CNAME/A/MX/etc. record with a zero scoped address in the ECS data, so that it is globally cached. This would also apply to any NODATA or NXDOMAIN responses, whether for AAAA records or any other type.

3. whether ipv6 cache affect ipv4 cache in 8.8.8.8 ? 

ECS responses are cached by address scope; even zero-scoped ECS addresses will be only be used for queries from the same address family (IPv4 or IPv6).

[3643...@qq.com]

Hello, I am studying the security content of IPv6 DNS direction recently, and one of the security issues involves whether the edns-client-subnet under the condition of v6 (because it will disclose the real IP address of the client host to the recursive server) will cause a large number of real v6 address leakage.However, I am not particularly familiar with its overall deployment, so I would like to ask you about the deployment in this aspect,THANK U VERY MUCH