Home / Blogs

(DNS) Security Protocols Do What They Say on the Tin

DNS-over-TLS has recently become a welcome addition to the range of security protocols supported by DNS. It joins TSIG, SIG(0) and DNSSEC to add privacy, and, in the absence of validating stub resolvers, necessary data integrity on the link between a full-service resolver and the users’ stub resolver. (The authenticated source feature of TLS may also offer some additional benefits for those of a nervous disposition.) Good stuff.

What is not good stuff is when implementers suggest that any specific security protocol is capable of doing more than it says on its tin.

Protocol designers, and especially security protocol designers, are cautious people and careful to define precisely, or as precisely as the English language is capable of, the functionality of their design in its specification (in our case RFCs).

It has been suggested that ubiquitous DNS-over-TLS (stub to resolver, resolver to authoritative sources) is functionally equivalent to DNSSEC. It is not. Both DNSSEC and TLS do what they say on their tin. No more and no less.

DNSSEC is designed to ensure DNS data originates only from the authoritative source and is unchanged at the termination of the DNSSEC scope—when the DNS data is validated. It does so by digitally signing the zone (technically RRsets within the zone) using RRSIG records and by providing a verifiable chain of trust, typically via the DNS delegation hierarchy (DS records). DNSSEC can be viewed as an application-specific content security and authentication protocol. That’s what it says on its tin (RFC 4033 and many others).

TLS provides integrity, privacy and source authentication for data supplied to the TLS software via some API (not defined by TLS) from some application (not defined by TLS). The application may obtain the data it supplies to TLS by self-creation, from RAM, from a filesystem, a remote location or by some other esoteric process, any or all of which may be vulnerable. If the data supplied by the application, for example, a web server, a DNS resolver or a mail system, is clean, corrupt, has been hacked or is otherwise maliciously modified TLS will simply ensure the clean, corrupt, hacked or otherwise modified data is delivered unchanged and confidentially to the TLS peer. TLS is a powerful and highly efficient general purpose (non-application specific) secure communications and end-entity authentication protocol. That’s what it says on its tin (RFC 8446 and many others).

(There is one application specific data content element within TLS. During the TLS handshake phase a certificate, typically an X.509 certificate, is normally supplied and validated before the connection can be established. The certificate validation process is not specified within TLS but determined by the certificate type. For example, the X.509 certificate validation process is defined by RFC 5280 and others.)
TLS plays a vital role in securing access to many services and will contribute its own unique capabilities to DNS.

The bottom line: If you want your clients to have privacy, secure last-mile communications and are content to hope the data you are sending is correct, then DNS-over-TLS is for you; If you want your clients to have privacy, secure last-mile communications and want to ensure the data you are sending is correct, then you need both DNS-over-TLS and DNSSEC.

There is, however, another reason to welcome DNS-over-TLS. TLS has been around, in one form or another (including its SSL ancestor), for about 26 years, DNSSEC for about half that period. TLS/SSL has had 5 minor surgeries and one, recent, major surgery (TLS 1.3). TLS penetration rates are high, partly driven by the inherent benefits of the protocol, partly by threat of obliteration by the search engines if not implemented. (Does that constitute a modest carrot and a very big stick?) Whatever the reasons, TLS has always taken a pragmatic approach to implementation while maintaining the highest levels of security. Perhaps the DNS community needs to review critically the implementation details of DNSSEC with the objective of radically improving its penetration rate. Learn some lessons from its new (TLS) stable mate.

DNSSEC is, arguably, the only application-specific content security protocol the Internet has. That has meant wrestling with its unique problems. But let’s stop fighting the theory wars of the past (DNSSEC works) and admit we need some, perhaps major, surgery to make it practical.

By Ron Aitchison, Consultant, developer, trainer and author

Filed Under


I think the biggest problem is the Todd Knarr  –  Sep 16, 2018 12:45 AM

I think the biggest problem is the difficulty finding a DNS provider who actually supports DNSSEC at all. The ones that do don’t include it in their basic packages either, which is a hurdle for personal and non-commercial domains.

Agreed. But it's a chicken and egg Ron Aitchison  –  Sep 17, 2018 1:32 AM

Agreed. But it's a chicken and egg situation. If there was more demand from , especially high-value, domain owners for DNSSEC the providers would be falling over themselves. So we have to be realistic (and I think radical) in identifying the road blocks. My next post will make a number of suggestions - varying from ground well covered by many commentators to the outrageous. Regards

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

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign


Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API