* 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-).