[Dnssec-deployment] DNSSEC aware recursive name servers

Paul Vixie vixie at isc.org
Sun Aug 7 13:03:59 EDT 2011

> Date: Sun, 07 Aug 2011 04:28:03 -0500
> From: Matt Thompson <mthompson at hexwave.com>
> ... The user should trust the recursive, and the recursive should (but
> currently does not fully) trust the authoritative response. The stub
> can just trust the AD bit.

ok, here's the scenario.  i'm at starbucks.  it's 2016.  dnssec is so far
deployed that homebanking.wellsfargo.com no longer has an X.509 cert and
my browser does not even have a set of CA's in it.  IETF DANE is complete
and everybody's using it.

i ask the starbucks recursive validator for the AAAA RR for wells fargo
and it tells me, with the AD bit.  i contact the TCP/443 listener at that
address and it gives me a self signed cert with some indication that i can
find the hash of that cert in DNS.

i ask the starbucks recursive validator for the "key hash" RR for this
cert and it gives me one, with the AD bit set.  it matches.  so up comes
the login screen, in goes my credentials, and there i am paying bills and
transferring balances, all happily.

except it's never going to happen.  noone should though many would trust
starbucks for a secure introduction to wells fargo.  a system that would
place that kind of control (and that kind of liability!) in starbucks'
hands would never even be built.

> The problem with DNSSEC that nobody has been able to answer is that
> without a policy that says "I *require* DNSSEC validation for
> mybank.com" or that every RRset must be signed within a given zone
> .. what is a recursive to do when it gets a response with *NO* RRSIG
> or DS? Without breaking everything, it is going to pass along the
> response without validation. Unless I'm wrong I think this issue needs
> to be addressed first.

if there's supposed to be an RRSIG or DS you'll know it before you ask
and you'll know, if you don't get one, that you're getting spoofed.  that
part is well covered.

> Also at the end of the day, just because I trust an RRset doesn't mean
> I trust the network I'm on for the subsequent connection. If you don't
> trust the network, use a VPN.

i don't think we can build a scalable global e-commerce system on VPN's
at the end user level.


> Date: Sun, 07 Aug 2011 05:34:36 -0500
> From: Matt Thompson <mthompson at hexwave.com>
> > For example, the ISP usually operates the recursive.  The ISP is not
> > the user, and sometimes cannot be trusted to leave the DNS responses
> > intact without violation of Integrity.
> Back to my point of what does the stub do if all DNSSEC records are
> stripped by your ISP, or a middlebox?

back to my answer, above.  any dnssec aware requestor will know in advance
whether it should expect dnssec metadata from the responder.  if it does
not arrive then the requestor will know there's something wrong.

however, we don't get that far.  in your example, the stub is probably
talking to a non-dnssec-aware recursive server, so it cannot itself be
dnssec-aware unless it's avoiding that recursive server and using another.
such avoidance and such alternative usage is a form of "defense in depth"
and will require a lot of new services (proxies, vpn's, dns-over-https,
etc) to be deployed.  that's why we're talking about those in this hydra
(we can't call this a thread any more.)

> ... I don't think it's practical for the stub to support DNSSEC. ...

i hope you're wrong.

> Using the method in my preliminary draft each query/response is still
> a single UDP packet and the server would do an O(1) average case
> lookup of the session ID. There would be 64 bits of knowledge required
> (32 bit session ID and 32 bit client IP) for an external attacker to
> cause the server to branch past a hash table lookup. If the client
> doesn't have a session, it just sends a small denial packet so a valid
> client will re-establish a session.
> AES-GCM and ECC is also *very* lightweight (CPU cycle wise) and will
> easily run on the smallest memory constrained devices (I've used these
> algos on 16bit TI MSP430 micros with 48k of flash and 10k RAM). ECDH
> and ECDSA would be the most CPU intensive but are only called during
> key negotiation.

i'd rather use SIG(0) in transaction mode then see the above implemented.

More information about the Dnssec-deployment mailing list