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.