IETF93: Getting your ducks in a row in DNS

By on 22 Jul 2015

Category: Tech matters

Tags: , ,

Blog home

Lock and key
Image credit: Sachin Patekar

A lot of DNS related discussions here at IETF93 are about the consequences of DNS being secure. Some of the most asked questions include:

  • Is DNSSEC key rollover safe to perform? How do we know? How can we find out?
  • If we have DNSSEC, how can we leverage it to achieve benefits in other protocols? For instance, given DNSSEC, can we pass DANE records to secure a TLS session so the client can bootstrap TLS even if the intermediate DNS service cannot do DNSSEC?
  • If we have alternate names pointing to the same information but in different domain spaces, how can we indicate they relate?

How should we defend the DNS?

The interesting thing that emerges (for me at least) is that for most, if not all, of these questions to have any utility, DNSSEC needs to be a given. For example:

  • If nobody is using DNSSEC, the question of key rollover risks is moot: no users would mean no damage.
    At APNIC Labs we know this is not true, because we’ve been measuring the use of DNSSEC, as well as the consequences of changes in DNSSEC, which potentially break validation.
  • The TLS trust on the passed data depends critically on DNSSEC to secure the statements being proffered in the DNS. If the TLSA record is not itself signed, nobody can trust the ‘blob’ of data being passed over.
    Therefore this dependency of TLS-DANE is quite explicit. DANE is, in fact, the delivery of substantive improvements in security to applications protocols precisely because DNSSEC exists.
  • Adding information to signal intent and ownership in domain names implies a two-way trust in the data being expressed. It’s very likely that DNSSEC is going to be required to trust the data.

Hop-over DNS with TLSA_DANE

It’s often said there are only three critical elements to the modern Internet:

  1. Unique endpoint addresses (The RIR address distribution and management function)
  2. A naming scheme to find the addresses (the DNS)
  3. A way to send the packets (routing).

What emerges from the DNS working groups (and there are several of them) is the centrality of DNSSEC to this situation.

But the DANE question also points to the problem of emerging DNS software, able to handle DNSSEC related queries and the validation checks.

TLSA-DANE (as discussed in the DANE working group) offers a way to ‘hop-over’ the intervening DNS systems if they aren’t yet able to deal with DNSSEC.

It doesn’t take away the need to have valid DNSSEC signed data, but it does take away the need to be able to use the DNS to ask the questions!

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

Top