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

[Florian Weimer]

* Emin Gun Sirer:

>>Won't DNSSEC deployment fix the security problems in DNS?
>
> No. DNSSEC is better than nothing, but it's not a complete fix. In our
> SIGCOMM'04 and IMC'05 papers, we identified two intertwined but
> separate problems about the shape of the DNS dependency graph. One
> problem is that there are many nameservers with known exploits which
> lead to scripted attacks against nameservers, while another problem is
> that the name delegation graph has bottlenecks which lead to
> denial-of-service attacks. Clever attackers can combine these two
> types of attacks to extend their reach. 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?

>>Suppose glue _is_ present, doesn't that fix everything?

I don't think your analysis is sufficient because it does not deal
with the very common case of glue coming from a large parent zone.

In addition, it is slightly irrelevant because once you've got the
ability to indirectly certain queries to the resolver (which is a
reasonable assumption because many services automatically generate
name lookups), it is often possible to replace data learnt from glue
with original data learnt from authoritative servers (which are, under
your assumption, compromised).

> Educational institutions (say, NYU) has no fiduciary responsibility
> to people who own DNS names (say, in the Ukraine), yet may well be
> in a position to control large sections of the same namespace (NYU
> appears in the dependency graph of all names in the Ukrainian
> namespace).

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

> This creates two problems: educational nameservers become more
> prominent targets because they play a large role in DNS dependency
> graphs, and pose a legal liability for the university should a
> nameserver get compromised.

And it nicely cuts down the dependency graph for them, provided that
they also load the zones into their resolvers. 8-P

> 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?

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.

In addition, if the server is authoritative-only or does not support
DNSSEC, certain classes of bugs do not apply.  Since such a
configuration is hard to detect from the outside, I presume that your
assessment is based on the assumption that all code paths are actually
usable.

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