Home / Blogs

If You Build It, They Will Come.

Don't miss a thing – sign up for CircleID Weekly Wrap newsletter delivered to your inbox once a week.
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

 
   

Comments

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

Sponsored Topics

Promoted Posts

Now Is the Time for .eco

.eco launches globally at 16:00 UTC on April 25, 2017, when domains will be available on a first-come, first-serve basis. .eco is for businesses, non-profits and people committed to positive change for the planet. See list of registrars offering .eco more»

Boston Ivy Gets Competitive With Its TLDs, Offers Registrars New Wholesale Pricing

With a mission to make its top-level domains available to the broadest market possible, Boston Ivy has permanently reduced its registration, renewal and transfer prices for .Broker, .Forex, .Markets and .Trading. more»

Industry Updates – Sponsored Posts

Leading Internet Associations Strengthen Cooperation

Global Domain Name Registrations Reach 329.3 Million, 2.3 Million Growth in Last Quarter of 2016

i2Coalition to Present Tucows CEO Elliot Noss With Internet Community Leadership Award

Verisign Releases Q4 2016 DDoS Trends Report: 167% Increase in Average Peak Attack from 2015 to 2016

Michele Neylon Appointed Chair Elect of i2Coalition

Neustar to be Acquired by Private Investment Group Led by Golden Gate Capital

Verisign Q3 2016 DDoS Trends Report: User Datagram Protocol (UDP) Flood Attacks Continue to Dominate

2016 U.S. Election: An Internet Forecast

Government Guidance for Email Authentication Has Arrived in USA and UK

Afilias Chairman Jonathan Robinson Wins ICANN's 2016 Leadership Award at ICANN 57

ValiMail Raises $12M for Its Email Authentication Service

MarkMonitor Supports Brand Holders' Efforts Regarding .Feedback Registry

Don't Gamble With Your DNS

Defending Against Layer 7 DDoS Attacks

Understanding the Risks of the Dark Web

New TLD? Make Sure It's Secure

Verisign Releases Q2 2016 DDoS Trends Report - Layer 7 DDoS Attacks a Growing Trend

How Savvy DDoS Attackers Are Using DNSSEC Against Us

Radix Adds Dyn as a DNS Service Provider

Facilitating a Trusted Web Space for Financial Service Professionals