DNSSEC, Incentives and the Color of Bicycle Sheds

It is the first day of the program of the Internet Governance Forum itself. The first workshop I attended was on “Understanding Internet Infrastructure.” It could also have been called “Everything you always wanted to know about the Internet, but where afraid to ask.” Three experts – Rick Lamb, German Valdez and Bill Woodcock – provided a concise and accessible introduction to the Domain Name System (DNS) and routing on the Internet.

Then the audience could ask whatever it wanted. Interestingly enough, many questions focused on the economics underlying Internet connectivity, such as how peering among ISPs works and how it can be “free”. To many of us, it is counter-intuitive how resilient and efficient connectivity emerges out of the self-interested behavior of ISPs. But it does. Bill Woodcock was able to explain why the ISPs’ incentives to drive down the costs lead to very efficient ways to exchange traffic. “Capitalism in its best form,” was how he summarized it. (By the way, a nice illustration of the incentives for connectivity recently emerged in the law suit between Cogent and Sprint.)

There was also a question about the DNS and the Kaminsky vulnerability. The discussion quickly moved to the deployment of DNSSEC. Someone asked why it wasn’t deployed more widely. The experts’ answer: Bureaucracy.

In my opinion this is not a very good answer. For the registries, bureaucracy may be relevant. But for the many thousands of ISPs and millions of domain name owners, a better answer is, again, incentives. DNSSEC suffers from a classic problem of positive network effects: Everyone needs to deploy it for people to get benefits, so the people who deploy it first bear the costs without getting anything in return – at least not until a critical mass of other have deployed it. This, of course, rewards an attitude “wait and see” rather than deployment.

Currently, there are no security benefits to having deployed DNSSEC, because the root zone is not signed – and also, of course, because ISPs haven’t adjusted their DNS resolvers and domain name owners have not signed their domains. Bill Woodcock euphemistically noted that the U.S. government was taking its time making the decision on whether to have ICANN sign the root or Verisign. The discussion then focused on which alternative was preferable.

What surprised me it that neither the experts nor the audience brought up the issue why we would want to locate that function within a single organization. If the session had made one thing clear, it was the power of decentralized, scalable architectures. Maybe the choice for a centralized solution is seen as a fait accompli. The DNSSEC standard was developed over several years and at one point opted for a centralized, hierarchical solution.

There are still options, however, to make it more decentralized, for example, through a trust anchor repository – something which has to be set up anyway. It seems there is no serious consideration of these options, in this session as well as outside it. Part of this may be the result of our conventional understanding about DNS. It reinforces thinking in terms of hierarchy. All visualizations of the DNS that I have seen depict it as a hierarchy: users are at the bottom, the root is at the top and the server that the user tries to reach is depicted again at the bottom, with the DNS resolvers, TLD and domain servers in between. Of course, in a technical sense, DNS has hierarchical properties. There is no need, however, to mirror that technical hierarchy with an institutional one. In fact, there are good reasons to resist such a solution and explore proposals to create a manageable amount of trust anchors or more decentralized ways to sign the root.

None of this emerged during the session. Instead, the discussion treated the decision to opt for either ICANN or VeriSign as the choice set.

This seems an example of the so-called Bicycle Shed Phenomenon. We tend to focus on the issues we understand, rather than on the issues that matter. The choice between ICANN and Verisign can be understood by everyone and you can argue one way or the other based on relatively straightforward concepts like market competition and accountability.

But while we spend all this effort on debating the color of the bicycle shed, the more urgent issue remain ignored: Why would we create an institutional hierarchy for a critical Internet resource? We did it with ICANN and can see the results of such a solution. It introduces a single point of failure, an institution that will have a bulls eye painted on its back from the beginning, a magnet to both political contention as well as security threats. When the DNSSEC standard was developed, the downsides of the ICANN model were not so clear. They are now. This is not to say that the standard needs to be completely overhauled. There are options that we can think about even at this stage.

Of course, after weighing all the evidence, we might still prefer such a hierarchical, centralized solution over more decentralized alternatives. But this critical debate seems to have ended before it was started. The session at the IGF explains why this is bad news: The extraordinary power of the Internet architecture has been the result of purposefully avoiding hierarchical solutions.

2 comments

  1. Anonymous

    Quick reaction:
    There are a few “Internet critical resources” that need to be centralized for the otherwise decentralized Internet to work. No ways around them seem to exist.
    In the case of the DNS hierarchy, it's namespace management that is centralized. The technical protocol operations are largely decentralized.
    In the case of DNSSEC, the de-centralized model may remain (in protocol operations, despite some difficulties). DLV and other TAR initiatives were mentioned. There is also “DNS Root Nameservice Substitution for DNSSEC Purposes” (http://www.connotech.com/six_roles_for_dnssec.pdf). Like other alternate DNS root initiatives, the most likely fate for these is to die because the centralized technical support required for the centralized namespace management will become adequate.
    It is important for these things to be discussed. But hopefully the much needed technical controls of DNSSEC are not delayed by misunderstanding of the issues at stake. DNSSEC deployment may proceed without change in the institutional arrangements.

  2. Anonymous

    When you say
    > DNSSEC deployment may proceed without change in the
    > institutional arrangements.
    I am suspect.
    IMO, there is a real risk that once a technical solution for root signing is in place that the institutional arrangements for root zone management become even more resistant to any future change. Such an outcome has nothing to do with the technical solution chosen to sign the root. It's easy enough for another institution(s) to assume that duty as long as they are competent. Rather, the problem is that once an institution controls something that might be leveraged to achieve other policy goals, they'll be very reluctant to relinquish that power.