On 1 Apr 2010, at 05:25, Jason Fesler wrote:
Our concern is more than just "os issues". Many apps today already ask for A/AAAA. The bigger issue to me is related to when the host tries connecting to the IPv6 address, using a route that exists but is either broken or suffers serious performance problems. Users see that as "Site Down". The percentage is high [see #1]; our business people would never let us deploy IPv6 unless we can mitigate it by things like selectively enabling IPv6 towards specific operators and end users that appear to have IPv6 "for real".
This is a valid concern. It does not and should not need to be addressed (excuse the pun) by making authoritatiev servers do stupid/ wrong/bad things. Others have already pointed out -- and it looks like they will have to continue -- that it is just wrong to make a name server return different data based on the network protocol used to make the query. For starters, the thing making the query to an authoritative server usually isn't the edge device. There's almost always a resolving server and/or crippled middleware boxes in the query path. And even if the edge device is IPv4 only, that doesn't mean it has no interest in IPv6 addresses. [It's not just SMTP delivery software that looks up MX records for instance.] Then there's the impact on caches. If your scheme goes ahead, IPv6-capable hosts will sometimes be told there's no IPv6 for some name because the resolver cached that from an earlier query over IPv4 which resulted in the authoritative server jumping to the wrong conclusion and then telling lies.
Why don't yahoo approach the problem the same way google has done for IPv6 to www.google.com? They only hand out AAAA records for this name to ISPs who can demonstrate they have solid IPv6 connectivity. This is ugly and distasteful. But it doesn't involve egregious damage to the DNS or resolver/cache behaviour.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
