In message <23491623.6382.1338256344974.javamail.r...@benjamin.baylink.com>, Jay Ashworth writ es: > ----- Original Message ----- > > From: "Mark Andrews" <ma...@isc.org> > > [ vix: ] > > > > meanwhile isc continues to push for ubiquitous dnssec, through to > > > > the stub, > > > > to take this issue off the table for all people and all time. > > > > (that's "the > > > > real fix" for nxdomain remapping.) > > > > > > You really believe that the outcome of that will be "we can't make > > > some > > > extra revenue off NXDOMAIN remapping because of DNSSEC? Well, the > > > hell > > > with DNSSEC, then"? > > > > People will route around ISP that do stupid things. They do so > > today. When your browers supports DANE there will be more incentive > > to ensure that DNSSEC does not break and more incentive to route > > around ISP's that do break DNSSEC. > > My personal reaction to that, Mark, is to say that you *badly* overestimate > the average Internet end-user (who make up, roughly, 80% of the endpoints, > in my jackleg estimation).
Google's recursive nameservers see plenty of traffic. > > Even a ISP that is redirecting on NXDOMAIN wants to be sure that > > it is a real NXDOMAIN not one that is spoofed do the path to the > > ISP's resolver will be DNSSEC clean and they will be validating. > > I'm not sure I understood that... Authoritative server ^ secure (DO=1 queries) v ISP's validating recursive server ^ insecure, redirect possible (DO=0 queries) v Stub clients. Putting it another way, the ISP doesn't want to be fooled even if it is fooling its customers. The ISP can't allow it's recursive servers to get the wrong answers for irs.gov, picking a signed domain, as they would look silly for not validating when there is a simple way for them to be sure that they are not being spoofed. > > Until stub resolvers set DO=1 pretty much ubiquitously this won't > > be a problem for ISP's that want to do nxdomain redirection. There > > still plenty of crappy DNS proxies in CPE routers to be replaced > > before you can just set DO=1 as a default without worrying about > > breaking DNS lookups. Even setting EDNS as a default is a issue. > > ...but that's probably because I don't understand DNSSEC well enough. The ISP <-> stub client path often has a additional piece in the path that is often a heap of steaming !@$! that doesn't do basic DNS let alone EDNS and DNSSEC. For example the Netgear router at home doesn't support DNS over TCP which is basic DNS (I'm using it as a access point not a router because of this). It's this sort of breakage that is stopping OS vendors changing defaults. This can often be bypassed by forcing the resolver to use the ISP's nameservers directly but you need to know to do that. ISP's validating recursive server ^ v CPE Router (broken DNS proxy code) ^ v Stub clients. You can also replace CPE Router with a broken firewall that is a steaming heap of !@#% when it comes to DNS packet inspection. These are harder to bypass and require someone to fix the configuration to replace/upgrade the box. > > That said we are starting down the long path to making it EDNS a > > default. DiG in BIND 9 defaults to using EDNS and "dig +trace" > > turns set DO=1 as well. You don't get things fixed if the breakage > > is not visible. > > We may be talking about different breakage here... > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org