I wanted to clarify a couple things on this thread. 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".
Re: getting clients to use and prefer IPv6 resolvers: this issue is not lost on us. Today, we don't have a clear solution on this issue that works for everyone. However, the access providers we talked to seemed to think this would become a resolvable issue (no pun intended). This may be via access provider specific means, or perhaps standards updates (and product updates) have happen by the time IPv6 gains significance on the internet. As to when the filter-aaaa hack works, there are very limited conditions: 1: Extra build option for the resolver. Not compiled by default. 2: Enabled in the configuration. By default, disabled. 3: Query is for AAAA. 4: Query arrived from client via INET, not INET6. 5: Results have both A and AAAA. Perform an "A" lookup if needed to satisfy this request. 6: Results are not signed. IPv6 only web sites, will still return the AAAA. Any site that is DNSSEC signed, will return results *unaltered*. We don't want to see DNSSEC broken. Yes, there is a "filter-aaaa break-dnssec;" option. We see it being useful in very limited cases (enterprise or lab networks where V6 routes might exist, but not public connected yet). It is just a tool; shoot your foot at your own risk. When DNSSEC is involved, we absolutely do not want to break any trust (or functionality). I look forward to the day when the majority of users are protected by DNSSEC. Hope this helps, -jfesler [#1] http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Colitti-IPv6atGoogle-RIPE58.pdf publicly shows this as 0.1%. Thanks, Lorenzo. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
