Re: NXDomain remapping, DNSSEC, Layer 9, and you.

[Mark Andrews <marka () isc org>]

In message <23491623.6382.1338256344974.JavaMail.root () benjamin baylink com>, Jay Ashworth writ
es:
> ----- Original Message -----
> > From: "Mark Andrews" <marka () 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                       jra () 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: marka () isc org