[dns-operations] Perils of Transitive Trust, followup.

[Emin Gun Sirer]

Florian Weimer wrote:
>> DNSSEC addresses the former
> > problem, but it does nothing to protect against denial-of-service
> > attacks against DNS servers.
> 
> To be precise, do you claim that DNS (and DNSSEC) does not provide the
> necessary degree of availability?  Or do you claim any flaws in the
> integrity part of DNSSEC?

The passage you quoted already answers your question: DNSSEC does not
protect against denial-of-service attacks, and the current DNS contains
many bottlenecks vulnerable to DoS.

How well DNSSEC will protect against integrity problems depends almost
entirely on how well keys are managed operationally. DNSSEC deployment
may be a no-op for security purposes if keys are online.

> very common case of glue coming from a large parent zone.

The security rests entirely on how the parent got the glue, as mentioned
before. Presence of glue, and the identity of the host serving it, is
immaterial.

> As far as I know, pro-bono DNS secondary service is very common at
> commercial ISPs, too.

Pro-bono DNS is a laudable service. Unfortunately, DNS delegations do
create a dependency no matter what the intentions are, and these
dependencies cascade.

> > The default behavior for BIND is to truthfully report version
> > numbers if version reporting is enabled.  While it is possible for a
> > production nameserver to pretend to have a flaw when, in fact, it
> > does not, this requires extra effort and makes little sense.
> 
> Is there a list of vulnerabilities (preferably CVE names) which you
> have included in your evaluation?

Those of you who read our SIGCOMM paper would have noticed Table 2.
We'll put up the vulnerabilities we used for our IMC paper on the web in
the next few days.

> For most of the past BIND 8 bugs, minimal patches which do NOT change
> the version number have ben published.  Typically, operators prefer a
> minimal change to an upgrade, so your claim that version numbers
> always match the patch level is a bit dubious.

If someone is running something that is advertised with a bad version
number, but have all the holes patched, they are running a de-facto
honeypot. We assumed that everyone who had version reporting turned off
was running a secure version of BIND, which underestimates potential
problems quite significantly given that 60% of servers did not respond
with version numbers.

> In addition, if the server is authoritative-only or does not support
> DNSSEC, certain classes of bugs do not apply. 

This is not prudent engineering practice. "Unexercised" code paths have
a habit of becoming exercised via benign configuration changes.

Overall, if the claim is "even though the dependency graph looks
vulnerable and there are 27000 hosts reporting version numbers with
well-known exploits, the overall system is secure because of some voodoo
behind the covers - trust me!" then, sorry, I'm not buying it.

> > DNS is already a large distributed hash table,
> 
> > We now know how to do better, and the time is ripe for rethinking
> > the architecture of the naming system.
> 
> Out of curiosity, how many lawyers are on your team? 8-)

None. My group builds and deploys systems. We did CobWeb, Corona,
Credence, closestnode.com and a host of other systems, and did not once
need to consult a lawyer. We intend to keep it that way.

Gun.