Re: [DNSOP] Misguided IPv4-IPv6 DNS trickery
one might actually extrapolate here (and maybe look back a couple decades) ... there used to be many different transports around - and about the timethe DNS "gel'ed", most had become vestigal. We are now in the evoultionary "fork in the road" when we have an emergent, new transport that demands attention. I suspect that as things evolve, giving the DNS the ability to be transport agile is a good thing. So I don't want to be too short-sighted here and bless one or two hacks that might ease todays transitional requirements. We should have some clear long-range thought on transport agility --bill On Thu, Apr 01, 2010 at 10:49:54AM +0100, Jim Reid wrote: > 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/. 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 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Misguided IPv4-IPv6 DNS trickery
On Apr 2, 2010, at 2:02 AM, Jim Reid wrote: > I agree with your point about the haggling Ted. I'm not so sure we > agree on the definition of a wrong answer. I think Ed's point about caching behavior proves you to be correct. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Misguided IPv4-IPv6 DNS trickery
On 1 Apr 2010, at 16:18, Ted Lemon wrote: On Apr 1, 2010, at 2:49 AM, Jim Reid wrote: Why don't yahoo approach the problem the same way google has done for IPv6 to www.google.com? They only hand out 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. Do you really think this is better than what Igor's proposing? Yes. Although it is unpalatable, it's the lesser of two evils IMO. What google are doing is essentially split DNS IIUC. records for www.google.* are only returned to ISPs who have some sort of IPv6 peering with them. The decision to supply IPv6 data isn't based on whether the query came in over IPv6 or not. I do have reservations about this approach because it's not just another sticking plaster over the gaping chest wound that is widespread IPv6 deployment. It's another way to avoid tackling that bigger issue or deferring it. I think a principled position can be taken that giving out wrong answers should not be done, but once you've decided that you're willing to give out wrong answers, we're really just haggling over the price. I agree with your point about the haggling Ted. I'm not so sure we agree on the definition of a wrong answer. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Misguided IPv4-IPv6 DNS trickery
On Thu, Apr 01, 2010 at 08:18:43AM -0700, Ted Lemon wrote: I think a principled position can be taken that giving out wrong answers should not be done, but once you've decided that you're willing to give out wrong answers, we're really just haggling over the price. Would "RA=0, NODATA" as a response to an query really be a wrong answer? -- Andras Salamon and...@dns.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Misguided IPv4-IPv6 DNS trickery
On Apr 1, 2010, at 2:49 AM, Jim Reid wrote: > Why don't yahoo approach the problem the same way google has done for > IPv6 to www.google.com? They only hand out 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. Do you really think this is better than what Igor's proposing? To me it seems worse. You're still giving out wrong answers - you're just giving them out to more devices this way. I think a principled position can be taken that giving out wrong answers should not be done, but once you've decided that you're willing to give out wrong answers, we're really just haggling over the price. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Misguided IPv4-IPv6 DNS trickery
> The bottom line is, that if a given provider's users send in too many > complaints about connectivity problems, the business folks will push for > dewhitelisting. That's bad for both the content and access provider sides > for a variety of reasons. Or, you could just refer them back to their ISP for support, which is how things work in the v4 world today. This is certainly my preference. Jason ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Misguided IPv4-IPv6 DNS trickery
On Apr 1, 2010, at 2:49 AM, Jim Reid wrote: > > 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. Actually, that dns hack is for resolvers. That's the only place the end client talks to a DNS server; that's the only place it makes sense to modify the result. It also only makes sense in a limited type of deployments; particularly those where clients are directly expected to ask the ISP resolver (or, where the router at the house forwards the request on the same protocol, without caching). Very limited use case. > Why don't yahoo approach the problem the same way google has done for > IPv6 to www.google.com? They only hand out records for this name > to ISPs who can demonstrate they have solid IPv6 connectivity. For our authoritative name servers, we will indeed be using a whitelisting approach. There is more than just the ISP offering solid service; even once an ISP offers it, there is still a significant time until the users have moved to it. The filter- option permits us to still whitelist a set of DNS resolvers, when our numbers indicate the user base has a higher than acceptable number of broken systems that would effectively consider us "site down". An alternative is have the access provider run two DNS pools - one for the v4-only provisioned user base, and one for the v6-provisioned user base (they'd whitelist just the latter). This alternative is certainly less controversial; but it is a larger footprint (for some, this is significant, where space/power is limited). Additionally, it doesn't do anything to mitigate the users with broken v6 routes. The bottom line is, that if a given provider's users send in too many complaints about connectivity problems, the business folks will push for dewhitelisting. That's bad for both the content and access provider sides for a variety of reasons. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Misguided IPv4-IPv6 DNS trickery
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/. 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 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
