> -----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 AAAA 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 AAAA 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 AAAA 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 > 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 AAAAs 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 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
