[dns-wg] What about the last mile, was: getting DNSSEC deployed

* Roy Arends:

> So what about joe end user. Are there initiatives to offer tsig/sig0/dtls
> between user and isp ? Are there initiatives to deploy code at the OS
> level, similar as to what the NLNetLabs and Sparta folk are building for
> the application level ? Are formentioned providers deploying either of
> these two sets of solutions to their end users ? Or is it all just
> security theater ?

I've been thinking about this recently (for a fairly tech-savvy user
base, but also including end users).  My hope was some design that
would enable us to add a simple "enable DNSSEC with DLV" switch to the
operating system.  The basic idea is like this:

  - Install a local BIND 9 resolver in forward-only mode.  Enable DLV
    (using ISC's zone if allowed).

  - Modify software which updates /etc/resolv.conf to tweak the BIND
    configuration instead.  In this configuration, /etc/resolv.conf
    will always point to localhost.

  - Perhaps modify the libc stub resolver to return better error
    codes, and update some interactive applications to make use of
    them.

  - If necessary, tweak BIND so that it exposes a DNSSEC-less view to
    applications, and does not request validation from the forwarders.
    (For instance, we must not exceed the 512 byte size limit on the
    application interface when the original configuration doesn't.)

  - Get some banks or other high-profile sites to participate in the
    DLV project, so that all this actually makes sense.

However, I fear that many users are located on networks which do not
offer a transparent DNS transport: the forwarders they use are not
capable of handling requests for DNSSEC-related RRs for some reason.
Perhaps they discard resource records they deem strange, or they have
got problems with large responses.  A typical setup might look like
this:


     +--------------+
     | ISP resolver |
     +--------------+           similar configuration
              |                 at a different ISP
              |                      :
        /---------------\            :
        | Access Router |            :
        \---------------/            :
               |                     :
               |                     :
             /-----\                 :
             | CPE |.................:
             \-----/    (actually, the CPE is a cheap NAT device)
                |
             +------+
             | Host | (running a DNSSEC-aware resolver locally)
             +------+

The CPE typically runs some kind of DNS forwarder (can be a simple
destination NAT, but might be an application proxy), and advertises
itself as caching resolver to the host via DHCP.  The access router
might inspect DNS traffic and transparently proxy it.  It's not too
uncommon that the "ISP" the end user subscribes to switches their
subcontractor, so that you can get hooked to a completely different
infrastructure over night.  The subcontractor might use anycast or
load-balancing across different implementations to provide the caching
service.  If the host is a real mobile device, the picture is much
more complicated.

There are a couple of things that can go wrong here: ISP resolver,
access router (if proxying) and the CPE must be transparent for DNSSEC
traffic.  It's not sufficient to check this at installation time.
It's hard to cache this information, too (thanks to load-balancing).
Perhaps these fears are unwarranted; fairly distributed testing would
provide us with some assurance that this might actually work.

Unfortunately, the real showstopper I see is that you cannot tell an
attack from an infrastructure change that happened to break DNSSEC.
But we need to provide some kind of fallback in case DNSSEC breaks
because we absolutely must ensure that we match plain DNS in terms of
availability.  (And I don't think yet another security indicator
visible to the end user is the answer.)

Running name resolution over 443/TCP to some central resolver
infrastructure suddenly seems much more attractive, doesn't it?
However, I don't like the way this facilitates large-scale
interception of DNS traffic (with end user addresses intact, so that
you won't call me a hypocrite 8-).