I think you missed something slightly. Based on the proposal the connectivity to the recursive name server from the client is being leveraged as *partial* indicator, not the connectivity from the recursive name server to the authoritative name server(s).
John On 4/1/10 6:41 AM, "Mohacsi Janos" <moha...@niif.hu> wrote: > > > > 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-IPv6a >> tGoogle-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 ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
