[Dnssec-deployment] DNSSEC aware recursive name servers
vixie at isc.org
Fri Aug 5 22:03:29 EDT 2011
> Date: Fri, 5 Aug 2011 22:41:30 +0100
> From: Ben Laurie <ben at links.org>
> > stub validation is going to be needed by some apps at some
> > times. especially apps like SSL/TLS startup with self-signed keys
> > backed by DNSSEC (see IETF DANE WG for details.)
> Absolutely. I didn't say anything about where the cache lives. Right
> now, if you want to rely on the cache, then you pretty much have to
> manage it yourself.
i'm not sure that i want a cache everywhere, where "cache" can mean more
storage than even a postmodern smart phone should have to use for this
and can also mean the need for the same type of "clear path DNS" that a
full recursive name server needs to have, which is increasingly rare in
the networks my smartphone will be able to join.
> Maybe there's some beautiful future world where I can rely on someone
> else's cache. I look forward to it.
as a relying party i want a trust anchor that i (the operator) can control
and then i want a fast way to say "give me the whole chain from the qname
back to that trust anchor", ideally in a single udp exchange (one round
trip) but at least in a single tcp exchange (three round trips). alas,
what we're going to be doing is one failed udp exchange (stopped by NAT/FW)
followed by one tcp exchange to a remote proxy back home (via TCP/443 and
static non-CA-based keys for same.) to that end, kaminsky and i have been
socializing an EDNS OPT block that would allow a requestor to state a TA
and thereby solicit a full chain from that TA to the QNAME. needs coauthors.
and even that will fail as more and more nations implement https MiTM at
their borders in order to stop terrorism, tax evasion, sedition, etc. the
various forces driving the internet's evolution are often at cross purposes.
i'm hoping that commerce can get there first since it's often a sacred cow.
More information about the Dnssec-deployment