On Wed, 31 Mar 2010, Jason Fesler wrote:
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.
I still cannot see, how can you assses the quality of IPv6 connectivity of
someone, based on a DNS query. DNS queries mostly are coming from the ISP
public DNS servers. They are nothing to do with IPv6 connectivity of the
end-users.
Will it be effective?
Best Regards,
Janos Mohacsi
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
