Home / Blogs

If You Build It, They Will Come.

Only two years after signing the DNS root zone, the powerful lure of a secure global infrastructure for data distribution is starting to reveal itself. It is illustrated clearly by two proposed technical standardizations that seek to leverage secure DNS. To some degree these developments highlight the strength of DNS institutions and how they might fill gaps elsewhere in the Internet’s governance. But an increasing reliance upon and concentration of power in the DNS also makes getting its global governance correct even more important.

The first, more widely known, development is the IETF’s ongoing DANE effort. The DANE standard proposes to improve the Transport Level Security (TLS) protocol, which is used worldwide to secure communication between applications (e.g., a browser) and host machines (e.g., a website server). DANE enables administrators of domain names to specify TLS cryptographic key material in a resource record stored in a zone file. Using DNSSEC, an application could validate the resource record with the practical result that communication between an application and host machine is probably more secure—a good thing.

Perhaps the most interesting aspect of DANE is that it takes TLS key distribution out of the hands of the browser/certificate authorities and places it with DNS operators. The browser/certificate authority regime has been shown to be susceptible to attack and lacking in clear lines of accountability. In theory, if an administrator puts signed key material in the DNS, an application can validate it starting from the single trust anchor maintained by ICANN. Like DNSSEC, DANE depends on registrars, registries and Internet service providers not tampering with signed data provided by administrators. Pressure to tamper with data could come from numerous sources, e.g., interests in intellectual property protection, advertising, surveillance, etc. At the end of the day, it will be the DNS contractual regime, the laws that govern the involved parties, and the extent to which those institutions are transnationally interoperable that determines how DANE contributes to various global public policy goals like free expression and free trade in information services. Expect the differences between governments, and their response to domestic pressures, to challenge that interoperability.

The second, and in our opinion, more interesting development is the more recently proposed ROVER (Route Origin Verification) effort which seeks to address the problem of misconfigured routing announcements, whether accidental or intentional. Similar to DANE, ROVER proposes to improve the inter-domain routing by creating new resource records published in the secure reverse DNS (i.e., the in-addr.arpa zone). Similar ideas have been proposed previously, but never took hold. The records would allow network operators to indicate whether an IPv4 or IPv6 prefix ought to appear in global routing tables and identify authorized origin Autonomous System Number(s) for that prefix. This is the same data (i.e., Route Origin Announcements) which appears in the Resource Public Key Infrastructure (RPKI) being managed by some RIRs. ROVER would facilitate the comparison of validated records stored in the secure reverse DNS against route announcements being made on the Internet. Discrepancies could be flagged and lead to further action taken by the operator.

Again, the most interesting aspect is the interplay between technology and institutional power. The technical community has been debating the merits of Secure DNS vs. RPKI. The debate occurs in the shadow of the major, ongoing concern for network operators concerning RPKI, i.e., how it could allow certificate authorities (e.g., the RIRs) to impact routing. This concern is further complicated with Border Gateway Protocol Security (BGPSEC), which proposes incorporating cryptographic signing and validation of route announcements directly into the BGP. As an alternative, ROVER suggests leveraging the certified resource allocation data stored in the RPKI (or elsewhere) to create and validate route announcements in the secure reverse DNS. But it allows operators to independently apply that data to routing decisions. If a certificate authority revoked a certificate it would not impact routing unless the operator allowed it to. Less appreciated, however, is that ROVER potentially shifts route announcement data, typically stored in the decentralized Internet Routing Registries (IRRs) now, into the hierarchical secure DNS. Given this, the operation and governance of a few zones, namely .arpa and in-addr.arpa, becomes critical. Those zones are currently managed by ICANN. Its use for routing purposes may raise contention that too much power is centralized with this organization. In theory, as manager of the in-addr zone, ICANN could regulate network operators via contract, similar to the way it does some TLD operators. This will need to be examined more closely.

By Brenden Kuerbis, Internet Governance Researcher & Policy Analyst at Georgia Tech

Filed Under


A Way to Prevent Route Hijacks? Christopher Parente  –  May 24, 2012 2:53 PM

Very interesting article. I’m not an engineer, so hope you’ll indulge me with some clarifications.

So could ROVER prevent route hijacks, even if BGP is not made secure? Same question in reverse - if BGPSEC is implemented, would ROVER be necessary?

I would have chosen a different title for this post. If the history of DNS shows anything, it’s that just building something will not change established behaviors without a lot of time and effort.

Look at how long DNSSEC languished, because there was no compelling business model to offset implementation costs. I’d bet registrars would say there still isn’t one.

So could ROVER prevent route hijacks, even Brenden Kuerbis  –  May 30, 2012 4:52 PM

So could ROVER prevent route hijacks, even if BGP is not made secure? Same question in reverse - if BGPSEC is implemented, would ROVER be necessary?
Two different things. The ROVER debate is over which infrastructure (i.e., secure DNS or RPKI) should be used to distribute data for authenticating route origination (i.e., what ASN can use what address block to make an announcement). BGPSEC proposes to do something else, namely extend RPKI functionality and allow validation of an AS path (i.e., a series of intermediate ASes between origination and destination routers that form a directed route for packets to travel)
I would have chosen a different title for this post. If the history of DNS shows anything, it's that just building something will not change established behaviors without a lot of time and effort.
Agree, successful transition to a new standard can be susceptible to numerous hurdles - economic, governance, technical, etc. The point of the title was that the secure DNS (and its governance structure) was being considered as an alternative to deal with some routing security issues.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



IPv4 Markets

Sponsored byIPv4.Global


Sponsored byDNIB.com

Threat Intelligence

Sponsored byWhoisXML API

Brand Protection

Sponsored byCSC

Domain Names

Sponsored byVerisign


Sponsored byVerisign

New TLDs

Sponsored byRadix