Re: [DNSOP] Ugly DNS ack
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" 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/. 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- 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 . >> 4: Query arrived from client via INET, not INET6. >> 5: Results have both A and . Perform an "A" lookup if needed to >> satisfy this request. >> 6: Results are not signed. >> >> IPv6 only web sites, will still return the . >> >> Any site that is DNSSEC signed, will return results *unaltered*. We don't >> want to see DNSSEC broken. >> >> Yes, there is a "filter- 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
Re: [DNSOP] Ugly DNS ack
The intention is not signal the recursive name server to use a specific transport with authoritative name servers. The intention is to use the transport to determine how the recursive name server responds to the original query. On 4/1/10 1:41 AM, "Patrick W. Gilmore" wrote: > On Apr 1, 2010, at 12:29 AM, John Jason Brzozowski wrote: > >> Not necessarily, if a dual stack hosts communicates with a recursive name >> server over both IPv4 and IPv6 and other conditions are met then I believe >> it would be fine based on what was presented. > > What other conditions need to be met? > > I did not think there was any way for a host to signal a recursive NS to use > v6 or v4 transport. > > -- > TTFN, > patrick > > >> On 3/31/10 5:12 PM, "John Payne" wrote: >> >>> >>> >>> On Mar 31, 2010, at 3:19 PM, Dan Wing wrote: >>> >>>> Any host that sends its queries over IPv4 would lose >>>> IPv6 connectivity. >>> >>> >>> Isn't this a misdirection? >>> >>> I suspect it's more like: any (address family agnostic) clients of a dual >>> stacked nameserver will (non?) deterministically lose IPv6 connectivity to >>> DNS-determined destinations. >>> >>> ie, even if I only send DNS over IPv6 to my recursive nameserver, if it is >>> dual stacked (often beyond my control), and for this specific query it >>> prefers >>> IPv4, then I will not get an answer for my under this proposal. >>> >>> >> >> = >> 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 >> > = 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
Re: [DNSOP] Ugly DNS ack
Not necessarily, if a dual stack hosts communicates with a recursive name server over both IPv4 and IPv6 and other conditions are met then I believe it would be fine based on what was presented. John On 3/31/10 5:12 PM, "John Payne" wrote: > > > On Mar 31, 2010, at 3:19 PM, Dan Wing wrote: > >> Any host that sends its queries over IPv4 would lose >> IPv6 connectivity. > > > Isn't this a misdirection? > > I suspect it's more like: any (address family agnostic) clients of a dual > stacked nameserver will (non?) deterministically lose IPv6 connectivity to > DNS-determined destinations. > > ie, even if I only send DNS over IPv6 to my recursive nameserver, if it is > dual stacked (often beyond my control), and for this specific query it prefers > IPv4, then I will not get an answer for my AAAA under this proposal. > > = 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
Re: [DNSOP] Ugly DNS ack
What ultimately gets white-listed is the query source IP address, IPv4 and or IPv6. This in part depends on whether the authoritative name servers of the content provider are dual stack or not. John On 3/31/10 5:45 PM, "Dan Wing" wrote: >> On Mar 31, 2010, at 3:19 PM, Dan Wing wrote: >> >>> Any host that sends its queries over IPv4 would lose >>> IPv6 connectivity. >> >> Isn't this a misdirection? >> >> I suspect it's more like: any (address family agnostic) >> clients of a dual stacked nameserver will (non?) >> deterministically lose IPv6 connectivity to DNS-determined >> destinations. >> >> ie, even if I only send DNS over IPv6 to my recursive >> nameserver, if it is dual stacked (often beyond my control), >> and for this specific query it prefers IPv4, then I will not >> get an answer for my under this proposal. > > It's likely cached by the ISP's nameserver, so it would work > fine under Igor's proposal. And even if not cached, I would > expect the content provider's authoritative DNS server to have > whitelisted both IPv4 and IPv6 addresses of the ISP's > nameservers. > > -d > = 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
Re: [DNSOP] FYI: DNSOPS presentation
On 3/31/10 5:12 PM, "Dan Wing" wrote: >> -Original Message----- >> From: John Jason Brzozowski >> [mailto:john_brzozow...@cable.comcast.com] >> Sent: Wednesday, March 31, 2010 1:57 PM >> To: Igor Gashinsky; Dan Wing >> Cc: Andrew Sullivan; dnsop@ietf.org >> Subject: Re: [DNSOP] FYI: DNSOPS presentation >> >> On 3/31/10 4:37 PM, "Igor Gashinsky" wrote: >> >>> On Wed, 31 Mar 2010, Dan Wing wrote: >>> >>> :: Users running IE6 today are IPv4-only users. If/when they go >>> :: to IPv6, they will be running Windows 7 and whatever browser >>> :: is shipped by Microsoft. >> [jjmb] this is not what the Free people have indicated. I >> think this is a >> flawed assumption. >>> >>> Why do you say that? As far as I know, IE6 is an >> ipv6-capable browser, >>> as long as it's going to FQDN's.. So, what about IE6/XP users who >>> installed bittorent clients (or spyware/trojans) that >> enabled ipv6 for >>> them without the user knowing about it? >> [jjmb] Again from first hand experience, I can tell you there were >> unexpected non-trivial increase in P2P over IPv6 traffic. >>> >>> :: It seems solvably operationally, by asking ISPs to point their >>> :: IPv4-only subscribers at an ISP-operated DNS server which >>> :: purposefully breaks responses (returns empty answer), and >>> :: to point their dual-stack subscribers at an ISP-operated DNS >>> :: server which functions normally. >> [jjmb] Solvable perhaps, however, there are operational >> impacts that are >> non-trivial. Not to mention provisioning and in some cases financial >> implications. >>> :: >>> :: Advanced IPv4-only users wanting to do queries (e.g., >>> :: Teredo users, 6to4 users, etc.) should be sufficiently advanced >>> :: to point themselves at the ISP's normal nameserver or a >>> :: public DNS server on the Internet (e.g., Hurricane >>> :: Electric's, Google's, etc.). That won't affect users running >>> :: uTorrent (which uses Teredo to provide IPv6 connectivity) >>> :: because it doesn't do queries to find peers. >> [jjmb] what percentage of broadband users fall into the >> advanced category >> and will that be adequate to facilitate IPv6 adoption. I >> suspect no and >> this is not really an option in most cases for non-advanced users. > > Sorry, it appears I was not clear. > > I will describe it another way. There are two categories of ISP > subscribers: > > 1. If subscriber is provisioned for IPv6, they are pointed at >the ISP's DNS server which responds to normally -- >this is the ISP's "normal" nameserver. All is well. >DNSSEC works, even if the validation is done by the client. >No muss, no fuss. > > 2. If subscriber is NOT provisioned for IPv6, they are >pointed at the ISP's DNS server which responds to >with an empty answer. This helps with the transition >without losing eyeballs. DNSSEC breaks if the client >queries and the client does DNSSEC validation. > >An advanced subscriber might be in this category (not >provisioned for IPv6). But that advanced user might want >to query and get an answer. That advanced user can >use the ISP's "normal" DNS server, or Google's, or >HE's, or opendns.org's, or whatever. An advanced >subscriber might want to do that to *purposefully* >run Teredo, or to analyze a packet trace that >includes IPv6 traffic (and do DNS reverse queries >on the packet trace), get full results from the 'host' >command, etc. > > Clearer? > > -d [jjmb] I see how you categorize things, the clarification does not, however, change some of my points. Having advanced users (people like us) manually configure their DNS servers to point to HE (for example) will pertain to a small percentage of the overall Internet using population that must start using IPv6 without special configurations. The former assumes there is a separate infrastructure in place with in the service providers which, as mentioned earlier, has non-trivial challenges. > >>> This is *exactly* what we are proposing -- the feature to >> return empty >>> answers would be needed for ipv4-only subscribers in order >> to keep them >>> ipv4-only. Also, if a fully ipv6-
Re: [DNSOP] FYI: DNSOPS presentation
On 3/31/10 4:55 PM, "Dan Wing" wrote:
>> On Wed, 31 Mar 2010, Dan Wing wrote:
>>
>> :: Users running IE6 today are IPv4-only users. If/when they go
>> :: to IPv6, they will be running Windows 7 and whatever browser
>> :: is shipped by Microsoft.
>>
>> Why do you say that? As far as I know, IE6 is an ipv6-capable
>> browser,
>> as long as it's going to FQDN's.. So, what about IE6/XP users who
>> installed bittorent clients (or spyware/trojans) that enabled
>> ipv6 for them without the user knowing about it?
>
> Yes, thanks for correcting me.
>
> I agree they will have a poor experience (due to Teredo).
>
> But Remi's point is that those same systems (running Windows XP
> and IE6) using 6rd will be denied the ability to access content
> via IPv6. Which removes an incentive for ISPs to add 6rd (and
> offload the NAT44 they may soon have to install).
>
[jjmb] this is true, this would be an issue for Free users that do not have
native IPv6. Free users that have native IPv6 connectivity would be fine,
however.
>> :: It seems solvably operationally, by asking ISPs to point their
>> :: IPv4-only subscribers at an ISP-operated DNS server which
>> :: purposefully breaks responses (returns empty answer), and
>> :: to point their dual-stack subscribers at an ISP-operated DNS
>> :: server which functions normally.
>> ::
>> :: Advanced IPv4-only users wanting to do queries (e.g.,
>> :: Teredo users, 6to4 users, etc.) should be sufficiently advanced
>> :: to point themselves at the ISP's normal nameserver or a
>> :: public DNS server on the Internet (e.g., Hurricane
>> :: Electric's, Google's, etc.). That won't affect users running
>> :: uTorrent (which uses Teredo to provide IPv6 connectivity)
>> :: because it doesn't do queries to find peers.
>>
>> This is *exactly* what we are proposing -- the feature to
>> return empty
>> answers would be needed for ipv4-only subscribers in order to
>> keep them
>> ipv4-only. Also, if a fully ipv6-capable user visits that
>> person's home,
>> the recursor would then be able to make the call on if they
>> should pass
>> through to that particular user or not... I am by no
>> means advocating
>> to make this behavior a default, just a feature.
>
> I'm saying this should be do-able entirely within the ISP's
> DNS, without coordination or involvement with the content
> provider's DNS.
>
> For example, imagine the ISP's nameserver has a new "allow--response"
> option that would be configured like:
>
> #
> # list IPv4 addresses that are known to have real IPv6 connectivity.
> # (e.g., this is all of the ISP's subscribers that are also
> # connected using 6rd).
> #
> acl _whitelist { 172.16.72.0/24; 192.168.1.0/24; };
> ...
>
> options {
> ...
> allow--response { _whitelist };
> ...
> }
[jjmb] So this would require the authoritative DNS servers of the content
providers to globally be advertising RR rights? What if IPv4 only
users are configured to use the same recursive name servers that IPv6
capable users are, we are back to points that have been made earlier related
to operational challenges, etc. What you describe above also looks a lot
like what what proposed during DNSOPs with the exception that it is assumed
that s are being advertised globally, right?
>
> Which should work until there is DNSSEC validation built into the subscriber's
> DNS client.
[jjmb] this would be problematic with DNSSEC, this has been acknowledged.
>
> I believe this is effectively what Nicholas described in
> http://www.ietf.org/mail-archive/web/dnsop/current/msg08339.html
>
> -d
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
=
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
Re: [DNSOP] FYI: DNSOPS presentation
On 3/31/10 4:37 PM, "Igor Gashinsky" wrote: > On Wed, 31 Mar 2010, Dan Wing wrote: > > :: Users running IE6 today are IPv4-only users. If/when they go > :: to IPv6, they will be running Windows 7 and whatever browser > :: is shipped by Microsoft. [jjmb] this is not what the Free people have indicated. I think this is a flawed assumption. > > Why do you say that? As far as I know, IE6 is an ipv6-capable browser, > as long as it's going to FQDN's.. So, what about IE6/XP users who > installed bittorent clients (or spyware/trojans) that enabled ipv6 for > them without the user knowing about it? [jjmb] Again from first hand experience, I can tell you there were unexpected non-trivial increase in P2P over IPv6 traffic. > > :: It seems solvably operationally, by asking ISPs to point their > :: IPv4-only subscribers at an ISP-operated DNS server which > :: purposefully breaks responses (returns empty answer), and > :: to point their dual-stack subscribers at an ISP-operated DNS > :: server which functions normally. [jjmb] Solvable perhaps, however, there are operational impacts that are non-trivial. Not to mention provisioning and in some cases financial implications. > :: > :: Advanced IPv4-only users wanting to do queries (e.g., > :: Teredo users, 6to4 users, etc.) should be sufficiently advanced > :: to point themselves at the ISP's normal nameserver or a > :: public DNS server on the Internet (e.g., Hurricane > :: Electric's, Google's, etc.). That won't affect users running > :: uTorrent (which uses Teredo to provide IPv6 connectivity) > :: because it doesn't do queries to find peers. [jjmb] what percentage of broadband users fall into the advanced category and will that be adequate to facilitate IPv6 adoption. I suspect no and this is not really an option in most cases for non-advanced users. > > This is *exactly* what we are proposing -- the feature to return empty > answers would be needed for ipv4-only subscribers in order to keep them > ipv4-only. Also, if a fully ipv6-capable user visits that person's home, > the recursor would then be able to make the call on if they should pass > through to that particular user or not... I am by no means advocating > to make this behavior a default, just a feature. > > Thanks > -igor > _______ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop = 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
Re: [DNSOP] Ugly DNS ack
On 3/31/10 3:19 PM, "Dan Wing" wrote: >> -Original Message- >> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] >> On Behalf Of John Jason Brzozowski >> Sent: Wednesday, March 31, 2010 10:38 AM >> To: Rémi Després; dnsop >> Cc: Ted Lemon; Jason Fesler; Igor Gashinsky >> Subject: Re: [DNSOP] Ugly DNS ack >> >> Remi, >> >> I hope you do not mind, I have take the liberty to pull some >> text from your >> original post and will reply to them here: > ... >>> 4. >>> "Return 0 answers for if, and only if: - Query comes >>> over Ipv4; - ³A² >>> record exists for same name; - DNSSEC is not used." >>> => This hack would NOT ONLY be "ugly" (as acknowledged by >>> their proponents), >>> BUT ALSO would BREAK some of the IPv6 connectivities that >>> are available today !!! >> >> [jjmb] I do not see how this would break IPv6 connectivity. > > Any host that sends its queries over IPv4 would lose > IPv6 connectivity. That includes common configurations of > hosts doing 6to4, Teredo, Windows XP, ISATAP, and any that > -- for whatever reasons -- are using an IPv4 DNS server instead > of an IPv6 DNS server. On many OSs, the DNS server list is > just a simple list and all DNS queries are sent to the > same DNS server. This is an issue with split-zone DNS and > multiple interfaces (in the MIF working group), but split-zone > DNS is another topic for another time. Igor's proposal > requires, effectively, accelerating host modifications to > perform A queries over an IPv4 interface and queries > over an IPv6 interface, which MIF is working on. How IPv6 > DNS servers are configured is another problem with RFC5006 > being experimental (which is being fixed) and lack of > RFC5006 implementations in routers (I know Cisco, and perhaps > others, lack RFC5006). > > -d [jjmb] some might consider this a feature given the issues and challenges with some of the transition technologies you mention. Support for RFC5006 from a residential point of view requires the home gateway/router to support the same. DHCPv6 (RFC3315) addresses this as well. > >> I do agree that there will likely be an impact to DNSSEC. >> >>> ==> This hack MUST therefore be flatly rejected. >> [jjmb] I see a number of people agree that this should be >> rejected. I can >> tell you from first hand experience over the past several >> months there are >> some enigmas here and that issues with 6to4 and other transition >> technologies present challenges to readying infrastructure for real >> broadband IPv6 traffic. And these challenges are likely not >> temporary. I >> suggest deferring rejection until the issues, challenges, and >> documentation >> have been documented. >>> >>> >>> If and when the mentioned OS problems are documented, it >> will be possible to >>> fix them with patches in OSes, where they belong. >> >>> >>> >>> Le 31 mars 2010 à 17:43, Ted Lemon a écrit : >>> >>>> On Mar 31, 2010, at 8:32 AM, Rémi Després wrote: >>>>> ==> This hack MUST therefore be flatly rejected. >>>> >>>> Unfortunately we don't have any control over what Yahoo or >> Google do to their >>>> name servers. I agree with you completely on what we >> SHOULD do, but if Igor >>>> decides to filter s on IPv4 queries, we can't stop him. >>> >>> Sure, and that's fair. >>> But it has to remains his problem, not an IETF >> specification problem. >>> >>>> We can refuse to endorse his solution, but really what's >> going on here is >>>> that Igor (and Google before him) have come to us in good >> faith to tell us >>>> about hacks they've done that they feel are necessary. >> We shouldn't >>>> discourage them from doing that, >>> >>> Agreed. >>> My strong reaction is only against this particular hack because: >>> - it is based on the idea that OSes cannot be patched where >> they are bugged >>> - it destroys legitimate connectivity for OSes that aren't bugged. >> [jjmb] see my point above, do you really assume the turn >> around time here is >> short? >>> >>> >>>> even if we do discourage them from doing the hacks. >>>> >>>> So to my mind, the question is whet
Re: [DNSOP] Ugly DNS ack
me the turn around time here is short? > > >> even if we do discourage them from doing the hacks. >> >> So to my mind, the question is whether or not we want to (and can!) have some >> say in what these hacks look like, > > We do want it. > (That's what I did in the technical explanation.) > >> not whether or not we should forbid them. > > "Flatly rejecting" the hack, as I proposed, doesn't mean "forbidding" it. > (Vendor makes its own choices anyway.) > It just means, in my understanding, a clear refusal to endorse it. > > > Regards, > RD > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop = 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
