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

[Suzanne Woolf]

On Fri, May 05, 2006 at 02:24:59AM -0400, Emin Gun Sirer wrote:
> Bear in mind that research prototypes should not be confused with
> deployed systems maintained by thousands of people and rolled into
> production settings. 

This is exactly the point several folks have tried to make: You appear
to be using issues of implementation and practice around a functional,
deployed protocol to make some kind of point about the superiority of
a different protocol, or type of protocol. It's comparing apples to
steaks and complaining that apples don't have any animal protein. As
given, your analyses speak a great deal about implementation bugs and
bad practice as vulnerabilities in DNS as deployed, but don't seem to
talk about protocol issues except, arguably, caching policies.

The analysis of implementation bugs and operational practice issues is
fine and valuable, which is why many of us contribute to such efforts
on a regular basis. But a) it's old news and b) it says nothing about
the underlying issues of either protocol quality or the risks
associated with poor implementation of a given protocol. That is, the
statement "the software and administrative practices implementing it
have bugs and fail sometimes" doesn't actually prove a deployed
protocol is bad or that a potential alternative is better, since it's
going to be true of both.

> You may have heard of a "beta test". BIND must have been in beta once.
> It had even more security holes then than it does now, and who knows
> which RFCs it complied with and which emails from Postel and other old
> timers it violated. If you chucked it out back then, no one on this list
> would be employed, and we'd all be mind-numbingly maintaining a
> giant /etc/hosts file.

This entire paragraph falls below the standard of technical discourse
you praised others for setting at the beginning of your post. Of
course people here have heard of beta tests; many have deployed them
and been responsible for the results on a much larger scale than you
are probably acquainted with. Sneering at BIND and speculating on its
history with "Postel and other old timers" is very popular on
Slashdot, but doesn't strengthen your contribution here. Stop it.

> CoDoNS embodies a groundbreaking way of caching in
> geographically distributed systems, provides a scheme by which records
> could be served securely by a giant cooperative cache regardless of
> their origin or physical servers, and outlines a backwards-compatible
> rollout path that preserves the investment in the current domain names.

Where is the protocol documented? I've read your web pages and your
academic papers, but they're not the requirements analysis, the
protocol design document or the specification. The architecture
document on the CoDoNS website appears to be about a page. "It's based
on DHTs and has different bugs than BIND" isn't enough. (e.g. the
description of the "home node" for a name doesn't tell me how
"neighboring nodes" to be standby "home nodes" are chosen, so I don't
know why you think that set of replication choices avoids the
fate-sharing in case of network failure that you called out as one of
the faults of legacy DNS. Why is this better than RFC 2182 and/or
anycast for your DNS server?)

If we're going to compare protocols, let's. We can stop talking about
the shortcomings of specific implementations and the things you can't
learn from prototypes, and start comparing apples to apples. Where is
CoDoNS specified? I'm particularly interested in on-the-wire
interactions between nodes and their triggering conditions, especially
if you're keeping more/different state than DNS uses.

Thanks,
Suzanne