* Robert Story:
On Sat, 24 Feb 2007 16:18:43 +0100 Florian wrote: FW> Unfortunately, the real showstopper I see is that you cannot tell an FW> attack from an infrastructure change that happened to break DNSSEC. FW> But we need to provide some kind of fallback in case DNSSEC breaks FW> because we absolutely must ensure that we match plain DNS in terms of FW> availability. (And I don't think yet another security indicator FW> visible to the end user is the answer.)
Well, you've got yourself painted into a corner here.
Probably true.
I don't think you can have a fallback, or you haven't added any security.
I'm concerned that I'm *reducing* security (regarding availability as a part of security). I also don't want to create a situation where organizations fear to DLV-enable their zones because a part of the client population is no longer able to access them. To some extent, this has already happened to AAAA records. Of course, this is motivated more by the categorical imperative, and not by actual market share. But you never know. 8-)
FW> Running name resolution over 443/TCP to some central resolver FW> infrastructure suddenly seems much more attractive, doesn't it?
Not particularly. Either way, you've got to get the ISPs to buy into a new way of thinking about DNS.
I think the idea (at least my version of it) is that you use a 443/TCP TLS connection to a resolver to bypass the ISP. The on-the-wire protocol would still be DNS with DNSSEC. The assumption is that the ISP can't do transparent rewriting of TLS connections and will leave the application traffic alone (which is no longer a safe assumption for 53/UDP or 53/TCP -- or 25/TCP for that matter).