Home / Blogs

If You Build It, They Will Come.

Brenden Kuerbis

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, Fellow in Internet Security Governance, Citizen Lab, Univ of Toronto. Kuerbis is also a contributor to the Internet Governance Project blog.

Related topics: DNS, DNS Security, ICANN, Internet Governance, IP Addressing, IPv6, Security

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:


A Way to Prevent Route Hijacks? Christopher Parente  –  May 24, 2012 7:53 AM PDT

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 9:52 AM PDT

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.

To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Industry Updates – Sponsored Posts

Verisign Q1 2016 DDoS Trends: Attack Activity Increases 111 Percent Year Over Year

Is Your TLD Threat Mitigation Strategy up to Scratch?

Domain Management Handbook from MarkMonitor

i2Coalition to Host First Ever Smarter Internet Forum

Encrypting Inbound and Outbound Email Connections with PowerMTA

US Court Grants DCA Trust's Motion for Preliminary Injunction on .Africa gTLD

Resilient Cybersecurity: Dealing with On-Premise, Cloud-Based and Hybrid Security Complexities

What Holds Firms Back from Choosing Cloud-Based External DNS?

United States Court Has Granted an Interim Relief for DCA Trust on .Africa gTLD

Verisign Releases Q4 2015 DDoS Trends - DDoS Attack Activity Increasing by 85% Year Over Year

Best Practices from Verizon - Proactively Mitigating Emerging Fraudulent Activities

Neustar Data Identifies Most Popular Times of Year for DDoS Attacks in 2015

The Framework for Resilient Cybersecurity (Webinar)

Dyn Weighs In On Whois

Season's Greetings - 2015 End of Year Message from DotConnectAfrica

Data Volumes and Network Stress to Be Top IoT Concerns

DKIM for ESPs: The Struggle of Living Up to the Ideal

Computerworld Names Afilias' Ram Mohan a Premier 100 Technology Leader

Verisign Mitigates More Attack Activity in Q3 2015 Than Any Other Quarter During Last Two Years

Protect Your Privacy - Opt Out of Public DNS Data Collection

Sponsored Topics

Afilias - Mobile & Web Services


Sponsored by
Afilias - Mobile & Web Services


Sponsored by

DNS Security

Sponsored by


Sponsored by