DNSSEC ‘and’ DNS over TLS

Willem Toorop recently posted an interesting article on the relationship between Domain Name System Security Extensions (DNSSEC) and the Domain Name System (DNS) over Transport Layer Security (TLS), titled Sunrise DNS over TLS, sunset DNSSEC?.

Willem is probably being deliberately provocative in claiming that “DoT could realistically become a viable replacement for DNSSEC”. If provoking a reaction was indeed Willem’s intention, then he has succeeded for me, as it has prompted this reaction.

In this post, I’d like to look at the roles of DNSSEC and DNS over TLS (DoT) and question how DoT could conceivably replace DNSSEC in the DNS.

Firstly, let’s look at what each of these technologies are attempting to achieve in trying to secure the DNS.

DNSSEC

DNSSEC adds digital signatures to DNS data. The addition of this digital signature is intended to allow a client of the DNS name resolution service to assure themselves of a number of qualities about the DNS response they have received.

Firstly, in a manner analogous to the intent of a handwritten signature on a document, the client can be assured that a validated digital signature attached to a DNS response implies that the DNS response is the DNS data that the original zone administrator had entered into DNS zone. It has not been altered with or tampered with in any way. The response is ‘genuine’.

Secondly, the client can be assured that the data is current. The date in the digital signature is not enough to ensure that the received information is the absolute latest information that is in the authoritative version of the DNS zone. There may be later information that has been published, but not fully propagated within the DNS, as is the case with the DNS with or without DNSSEC. At the same time the expiration date of the digital signature ensures that the receiver is not being passed a replay of stale information that was originally published earlier than a date specified by the original zone administrator. In other words, DNSSEC can assure the client that this is not a replay of stale information.

Thirdly, while DNSSEC allows a client to detect efforts to alter DNS data, it will not allow a client to correct the alteration. Failure to validate the digital signature of a signed response does not say how the response may have been altered, nor can it indicate what the ‘correct’ response may necessarily be, but validation failure is intended to clearly indicate that the response is not genuine, and therefore not trustable.

DNSSEC is a set of extension to the DNS, and it does not fundamentally change the DNS. A zone administrator adds digital signatures to the contents of a zone file by adding additional information into the zone through the use of DNSSEC-related Resource Record types (RRTypes).

A security-aware DNS resolver uses the digital signature that is attached to the DNS response of the queried DNS name (the ‘RRSIG’ RRSet of the DNS name). It then retrieves the sequence of in-zone DNS signing key information (DNSKEY RRSets) and DNSSEC Delegation records (DS RRSets) of the zone’s parent delegation hierarchy in order to assemble an interlocking chain of keys that link the Root Zone’s Key-Signing Key to the Zone Signing Key that was used to construct the RRSIG value. This is done in an analogous manner of a validation path in conventional Public Key Infrastructure (PKI) hierarchies. These are all ‘standard’ DNS queries and responses.

Put simply DNSSEC alters what you can ask from the DNS and augments the answers in what you get from the DNS, but not the way in which DNS questions and responses are passed over the Internet.

What does DNSSEC protect?

The objective of DNSSEC is to allow a client of the DNS to assure itself that the information that is passed back as an answer to a DNS query is an accurate and faithful copy of the information held in the authoritative servers. It should be able to do so irrespective of whether the response was assembled from a locally cached copy of the information or retrieved directly from an authoritative server in the DNS zone.

DNSSEC does not protect or restrict how the DNS query is handled. When you consider that a general performance objective of the DNS is to serve answers from local caches to the greatest extent possible, the identity of the server that is providing the data is not important. Whether the server is a recursive resolver, a non-authoritative server, or any other source of DNS information, is not important to the DNSSEC validation process. Once DNS data is digitally signed, the identity of the agent that provides the DNS response, or even the way in which the client has obtained the DNS response is not relevant. What matters is that the receiver can be assured that the data itself is authentic.

The only minor exception to this general observation, that how the answer was obtained is unimportant in DNSSEC, is indirection. Where the DNS has redirection pointers, such as CNAME, DNAME, NAPTR, MX, SRV and LUA records, the redirection record itself needs to be validated by DNSSEC along with the final answer. This additional validation is required to authenticate the logical connection between the name in the query to the name and the response that has been formed by this indirection.

DNSSEC can protect against various forms of manipulation of DNSSEC-signed data. Where responses are altered, the digital signatures will not validate, and clients can detect this mismatch as a validation failure. Where the middleware deliberately withholds data, including withholding the DNSSEC signature structure, DNSSEC validation can reveal to this effort to withhold data.

However, being able to identify that data has been altered and preventing the alteration in the first place are slightly different objectives. DNSSEC cannot prevent data manipulation of DNS responses, nor can it inform a client as to what the authentic response should have been.

DNSSEC does not encrypt DNS data. An observer can still look at DNS activity, irrespective of whether the data is DNSSEC-signed or not.

DNS over TLS

DoT wraps up a DNS protocol transaction within an encrypted channel. When a sender places information into a TLS-protected channel the data that arrives at the receiver is precisely the same data that was passed into the channel.

As well as channel protection, TLS offers some level of authentication of the remote party. In setting up a TLS connection the remote end demonstrates its knowledge of a private key that is associated with the DNS named identity of the remote server. The connecting client has also been provided the matching public key by the TLS handshake, and an attestation made by a trusted source that this public key corresponds to the named identity of the remote party.

For example, ‘Let’s Encrypt attests that you can trust that this public key is associated with the service named www.potaroo.net, because the TLS handshake provides the client with a public key certificate for www.potaroo.net signed by Let’s Encrypt’.

If the server takes a token and then encrypts this token using the server’s private key, then the client can use the corresponding public key to reveal the original token value.

Read: Let’s Encrypt with DANE

This implies that irrespective of the IP address of the service, the service is demonstrating that it is an instance of the named service by demonstrating possession of the private key that matches the public key contained in a trusted public key certificate.

DoT is not a datagram service. This is an important distinction because DoT uses a TCP transport as the basic connection protocol and layers TLS encryption and session integrity and then carries DNS over this connection. This means that DoT can avoid the issues associated with IP level fragmentation that occur with DNS over UDP and be able to carry larger DNS payloads.

This distinction is also applicable when comparing DoT with Datagram Transport Layer Security (DTLS) (RFC 6347), as DTLS is intolerant of IP level fragmentation.

What can DoT protect?

The DNS is a form of hop-by-hop protocol. When a client asks the DNS to resolve a DNS name, it does not necessarily direct the name resolution request to the authoritative name servers for that domain name. Instead, the client can simply ask its local recursive resolver. If this server already has a locally cached copy of the response, then the recursive resolver will provide the answer directly. The server will only generate a corresponding DNS query if the name is not contained in its local cache. The target of this query may be an authoritative server for the zone in question, or it may be another recursive resolver of some shape or form.

Answers are also treated in a hop-by-hop manner. The authoritative server will pass DNS data to a set of visible resolvers in response to queries. These resolvers, in turn, may pass DNS data to other resolvers, and so on, until data is passed to an end client. There is no requirement for synchronicity in this process. A caching recursive resolver will only query for a name when its locally cached copy has been held for the requisite local cache holding time.

The critical observation is that there is no requirement for a simultaneous set of paired connection states between each of these resolvers. Equally, there is no assurance that a virtual path from the authoritative server to a client exists to pass the DNS response. The entirety of the DNS can be seen as a set of pairwise operations where a server sends a response to a client.

TLS is a session protocol and is intended to allow a client and server to exchange data with a high degree of confidence that the data is not being altered or manipulated during transit between the sender and the receiver. In a hop-by-hop information propagation model, TLS can protect each instance of the network hop, but not necessarily protect the entire sequence of hops.

But even that limited level of protection may be enough. In today’s network, the protection of the session appears to be a fundamental issue. Many regulatory frameworks that attempt to restrict the content available to users, or monitor user activity for various reasons, do so by intervening in the DNS query stream. Blocking access to a site can be as simple as intercepting all DNS queries and responding with incorrect information for queries relating to the names of blocked resources or servers. This technique does not necessarily rely on the use of UDP. It simply relies on some form of network middleware intercepting all packets directed to remote port 53 and redirecting these packets to a local recursive resolver that is configured to operate promiscuously and has been configured with the applicable filtering rules.

The use of DoT prevents this form of DNS interception. When the TLS session is opened, the remote end has to demonstrate to the local client that it has possession of the private key associated with the name of the server. Once the session has been set up, the middle unit has to intrude upon the encrypted conversation if it wishes to alter DNS responses. This is intentionally a significant challenge.

Also, as the session is encrypted, any man-in-the-middle observer attempting to see the DNS transactions on the path between the client and the server will be unable to observe the content of the DNS queries or responses.

What TLS cannot protect is the transitive information flow from one hop to the next. If a client establishes a DoT session to a recursive name server, then it can be assured that the responses it receives are the responses that the recursive name server sent to the client. What it cannot know is whether these responses are a faithful and accurate copy of the information that was originally provided to the recursive name server, or whether the recursive resolver itself is performing some unauthorized manipulation of the DNS information.

This leaves TLS vulnerable to at least three forms of attack.

1. The first is crude disruption, where the attacker intrudes on the data path and discards or simply alters the payload of all TLS packets.
2. The second is more subtle and requires the attacker to subvert the client’s recursive name servers and corrupt their local DNS caches, and pass false information along the protected session.
3. The third is again subtle; it involves an attack on the domain name Public Key Infrastructure (PKI). If an attacker can subvert a trusted Certificate Authority to direct it to issue a fake domain name certificate for the server. This then allows the attacker to spoof the identity of the server and the client will incorrectly assume that the TLS session is terminated at the trusted server, whereas in fact the attacker is now feeding information to the client.

What if everyone did this?

Digital signatures cannot certify what is false. They can only certify accurate and complete copies of the original data.

In looking for false information, you either have to assume that everything is correctly digitally signed all of the time, and the absence of a digital signature, or the inability to verify a digital signature, is a reliable indication of untrusted data. The alternative is to have verifiable meta-information that indicates what data is comprehensively digitally signed, and what is not. The same assumption, that the absence of digital credentials when such credentials are expected or credentials that cannot validate, can be used as reliable indicators of falsified data.

While universal deployment of a security mechanism is a desirable assumption, it is rarely achieved. The practical consideration is that these security mechanisms must operate usefully in an environment of partial deployment, and that requires a robust verifiable mechanism of declaring in advance what is protected by digital credentials.

From such a perspective, the suppositions in Willem’s article that imagine the universal deployment of TLS breaks down. A client may have a secure TLS connection to a local recursive resolver, but that resolver may use a non-secured channel to reach its DNS servers. How is the client to know that while the data is being passed reliably from the recursive resolver to the client, the data itself may not have been reliably gathered by the recursive resolver? DoT simply can’t help here.

Equally, DoT does not sign the content, so if fake information is being passed along the secure channel DoT just can’t help.

Protecting content and carriage

It appears to me that DNSSEC and DoT address distinct security objectives and neither technology can realistically replace the other.

Protection of the integrity of content is necessary in a distributed system. Irrespective of how the DNS data is obtained it is necessary for a DNS client to assure itself that the data is authentic, and is a faithful and complete copy of the original authoritative data. DNSSEC can provide this assurance, and do so in an environment that also supports partial deployment.

Protection of the channel provides essential assurances to end clients. It can assure them that their own activities are not exposed man-in-the-middle observation and it allows them to be assured that the DNS server that they think they are communicating with is indeed the server that they intended. Almost.

This is not quite the full story.

There is still the open problem of the weakness in the widespread trust of the current domain name PKI. Trusting more than 1,500 Certificate Authorities (CAs) to always operate to the highest levels of integrity is such a lofty objective that it stretches rational credibility into the realm of credulity.

Contrary to the assertions of many PKI apologists, Certificate Transparency does not stop the problem. At best, Certificate Transparency might inform you that a problem occurred in the past.

It seems to me that DANE (Domain Name Keys in the DNS) really does play an essential role here, and using DANE and DNSSEC to reliably link a domain name to a public key seems to me to be the only effective response we know of to address the threat of rogue or corrupted CAs.

There is also the difference between DNSSEC in theory and DNSSEC as we see it working today.

In theory, a security-aware DNS client should not trust a recursive resolver’s DNSSEC validation outcome. It seems that the current practice is that clients rely on a security-aware recursive resolver to withhold the response and instead return a SERVFAIL response code if the response cannot be validated. If the response is valid then the recursive resolver sets the Authenticated Data (AD) bit in the response.

For a man-in-the-middle attack, this is ridiculously easy to tamper with as long as the session between the client and the recursive resolver is open. Here DoT helps, in that the man-in-the-middle simply cannot alter the data provided by the recursive resolver. In situations where the client has outsourced DNSSEC validation to the recursive resolver, the DoT improves the overall situation for the client in being able to trust the DNS answers it receives.

However, this still leaves me with a feeling that it’s just not quite enough. An appropriately cautious client would not outsource its validation and should insist on undertaking its own validation of DNS responses. Even if it uses a recursive resolver, it can still perform its own validation of responses. But it takes additional time, and now the entire issue of speed and responsiveness comes into play. It’s not only resolvers but for many browsers that speed is everything. Anything that slows down the ‘responsiveness’ of the browser in responding to a user is frowned upon.

When performed in an iterative manner DNSSEC validation can be tediously slow. Similarly, validation of DANE answers can be tediously slow. So, it’s fine to insist that user applications should exercise an appropriate level of security paranoia and not outsource their validation, but at the same time, it’s often contradictory to insist that these same applications operate in a highly responsive manner.

Maybe DNSSEC itself requires more tweaking, and the concepts explored in RFC 7901 of validation chain queries and responses might help.

However, in an unexpected manner DoT enters the picture once more at this point. The chain query and response model mandate the use of source-IP-verified transport for large payloads. DoT provides a TCP transport that can handle large responses, prevents spoofing of the client IP address, and allows the client to assure itself of the identity of the server that is providing DNS responses. All necessary attributes when managing this form of chain query and response.

Does the sunrise of DNS over TLS necessarily mean sunset for DNSSEC?

As should be evident by now, I don’t think it’s a case that DoT pushes DNSSEC into some lingering sunset afterlife. I think a secure and trustable DNS demands the use of DNSSEC irrespective of the fate of DoT.

But DNSSEC is just not enough. There is no doubt that the unencrypted trusting DNS as we use it is widely abused. DNSSEC can illustrate when DNS responses are being manipulated, but they can’t stop it.

DoT is not a panacea either, but the TLS channel can, at least, assure a user that when they want to pass their DNS queries to a server that they are prepared to trust, then their transactions with this server are private, secure and the server itself is the server the client intended to use.

It is critically important in a public communications system utility that every individual’s use of the system is private, secure, and operates with integrity. And the individual can assure themselves that this is the case. In this respect, both DNSSEC and DoT have an important role to play together.

In terms of a secure and trusted DNS, we need more security elements, not less.

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.