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

[Roy Arends]

On May 4, 2006, at 1:02 PM, Emin Gun Sirer wrote:

> Hi everyone,
>
> Our survey of DNS vulnerabilities was recently discussed on this
> mailing list. Having read through the comments, we noticed some
> confusion about some of the findings, and a dangerous myth that glue
> records can fix/patch over problems inherent in the DNS delegation
> graph.
>
> The goal of this message is to pop the "security-through-glue" myth,
> and clarify some of the other issues that came up during the recent
> discussion.


>> Your CoDoNS system proposes to use a peer-to-peer distributed hash
>> table (DHT) to serve DNS. Why would a DHT make sense for serving DNS?
>
> DNS is already a large distributed hash table, albeit with poor
> failure resilience,

Define poor failure resilience.

Don't classify implementation bugs under poor failure resilience.  
Implementation is not protocol. i.e. some implementations behave  
'better' then others.

If my local DHT node fails (the one with mass replication, serving  
hashes and capable of lookups and storing info), I lose both local  
names (since the local names might not been stored locally) and  
global names. Others might loose their names since the local node  
might be responsible for some part of the hash space.

Given that there are currently around 90 million names registered at  
various registries, one need to replicate that in the DHT  
infrastructure. A single name is probably stored at multiple nodes to  
avoid spof. Some DNS/DHT protocols recommend 6 nodes for a single  
name: 540M entries. They need to be distributed over N nodes. N is  
variable (ring can grow dynamically), but in general chosen to  
satisfy load and memory requirements. The larger N is, the more  
transactions needed to satisfy a request, the higher the latency.  
Some DHT systems solve this by caching request/response pairs that  
flow through the node (i.e. massive replication), or store copies at  
the closest nodes only.

There is an analogy. The replication happens in DNS as well, caching.

There is one point I'd like to stress. In DHT systems, there is a  
seperation between authority and service. The node serving a name (a  
key value, essentially a hash of a name) provides the service  
independent of its ownership of the original name. So how is  
authority proven in DHT, (i.e. I still would like to make sure not  
everyone is capable of a succesful put(hash(dnss.ec,A),address). The  
answer is something that is equivalent to DNSSEC, or maybe DNSSEC  
itself.

> slow lookup performance,

Note that DHT has a lookup algorithm as well, with its own scaling  
factors. This performance is enhanced by massive replication, the  
same trick DNS uses. Lookup performance is not a feature of DHT in  
general.

> and no support for
> unplanned record updates.

There is dynamic update. It can be used to grow of shrink the set of  
servers responsible for serving a zone. The added server needs to be  
provisioned as well in order for it not to be dangling. There is  
trickery that can do this, though outside the DNS protocol.

> Maintaining a secure namespace requires
> substantial manual effort.

These can be automated, but yes, this requires intervention. DHT does  
not suffer from this, i.e. put(key,value) is essentially location  
agnostic. But authority still needs to be dealt with.

> Administering DNS is not only difficult and expensive, but manual  
> administration can lead to inconsistencies and
> errors.

Yes. again, authority still needs to be dealt with. Whatever the  
solution for that might be, it is going to come at a price. The  
argument that such a thing can be automated holds for DNS as well.

> These are not surprising, given that DNS was designed over 25
> years ago when we did not know much about building failure-resilient,
> high performance, self-organizing distributed systems. We now know how
> to do better, and the time is ripe for rethinking the architecture of
> the naming system.

I am not convinced.

All the so called features that DHT has over DNS can be accomplished  
in DNS as well. It is even possible to map the entire DHT  
functionality to DNS (DHT over DNS).

> Looking forward to a more secure name system,

If you're interested in a more secure name system, you need to  
abstract protocol from implementation. Service from authority, etc. I  
don't want to handwave the glue issue that your survey has brought to  
light. That was interesting, but that is not an unsolvable issue  
(i.e. this can be fixed by using in-bailiwick glue, despite your  
concerns about the understanding that operational folk might or might  
not have about dependencies, or dispite your nice FAQ style list  
about what the operational folk need to know about gluelessness).

AFAIK there is a draft in the making that clarifies the term glue and  
highlights issues concerning glue. Some recommendation might come out  
of that too.

Maybe we should get rid of out-of-bailiwick glue. Maybe we should  
require (NS-BIS) that the NSDNAME is in-bailiwick. I dunno. What I'd  
like to see is a repetition of your survey, and see graph-depth and  
width measured. In other words, calculate all possible paths to a  
name, and calculate what percentage of the set of paths has issues.  
That is far more interesting than claiming that if a single node in a  
single path is vulnerable, the entire name is vulnerable.

Roy