DOH!

If you had the opportunity to re-imagine the DNS, what might it look like?

Normally this would be an idle topic of speculation over a beer or two, but maybe there’s a little more to the question these days. We are walking into an entirely new world of the DNS when we start to think about exactly might be possible when we look at DNS over HTTPS, or DOH.

We are now in a position to look at the standardization work in the IETF where the DOH Working Group is attempting to standardize DNS over HTTPs (https://tools.ietf.org/html/draft-ietf-doh-dns-over-https). The effort is directed to standardizing encodings for DNS queries and responses that are suitable for use in HTTPS, enabling a standard and interoperable mechanism for DNS names to be resolved over secure TCP connections using the HTTP/2 protocol. It’s a hybrid approach that attempts to integrate standard HTTP methods, error codes, and other semantics to the greatest extent possible, while still preserving the query response nature of the ‘traditional’ DNS name resolution protocol and the DNS resolution protocol format.

The primary focus of this working group is to develop a mechanism that provides confidentiality and connectivity between DNS clients (e.g., operating system stub resolvers) and recursive resolvers. In this way DOH is a direct substitution for the DNS over UDP step that allows a client-side stub resolver to pass queries to a recursive resolver and receive responses, where the IP and UDP wrappers are replaced with HTTPS wrappers.

What approach are they using here?

New URI labels for different URI name schemes are unfashionable these days, and the DOH work is no exception. Rather than recycle the earlier dns: URI prefix, the DOH approach uses the currently preferred mechanism, namely the use of a well known URI path of “/dns-query”. In this scheme a DNS query would look like:


   :method = POST
   :scheme = https
   :authority = dnsserver.example.net
   :path = /dns-query
   accept = application/dns-message
   content-type = application/dns-message
   content-length = 33

   <33 bytes represented by the following hex encoding>
   abcd 0100 0001 0000 0000 0000 0377 7777
   0765 7861 6d70 6c65 0363 6f6d 0000 0100
   01

This approach uses the existing binary DNS on-the-wire format, using a MIME data type of application/dns-message. When using the GET method the DNS query is encoded in Base64url, while the POST method places the binary DNS query in the body of the POSTed HTTP object, as per the above example.

While the IETF work in progress to standardize this technique uses the DNS on-the-wire format for the payload of DNS queries and responses, there are also implementations of DNS over HTTPS where the payload is formatted using JSON encoding, defined in RFC 8427 and denoted as application/dns+json. In all other respects these two approaches are identical, and the transformation between the one-the-wire format and a JSON format is very straightforward.

A DOH query and response using JSON formatting looks like:


  $ curl -s -H 'accept: application/dns+json' \
    'https://dns.google.com/resolve?name=www.potaroo.net&type=A' | jq

  {
    "Status": 0,
    "TC": false,
    "RD": true,
    "RA": true,
    "AD": true,
    "CD": false,
    "Question": [
      {
        "name": "www.potaroo.net.",
        "type": 1
      }
    ],
    "Answer": [
      {
        "name": "www.potaroo.net.",
        "type": 1,
        "TTL": 6399,
        "data": "203.133.248.2"
      }
    ],
    "Comment": "Response from 203.133.248.2."
  }

The HTTP 2xx response code is used for all DOH responses, irrespective of the DNS response code in the payload. The DNS responses also use DNS on-the-wire binary format, carried as the payload of the HTTP object.

My first reaction to this work was to struggle to understand where the win is with DOH. The additional HTTP wrapping seems to add little other than extraneous window dressing, and apart from the cheap thrills in trying to transform the external appearance of one protocol into the guise of another I couldn’t appreciate any advantages for this approach. If what we are after is the simple ability to conceal DNS queries within an encrypted channel, then the TLS part of DOH is doing all the heavy lifting here while the HTTP/2 component appears to be little more than a source of extraneous adornment. So why not just use DNS over TLS and move on?

DOT vs DOH

If the objective is to secure the communications between the stub resolver residing on the end user’s system and their chosen recursive resolver then, in theory, one could take DNS over UDP with a fallback to TCP and replace it with DNS over DTLS with a fallback to TLS and preserve all other aspects of the protocol operation. However, DNS over DTLS appears to have little to recommend itself in this context, and if we want to support larger DNS payloads, including various forms of omnibus responses, then perhaps we should just head straight to DNS over TLS (DOT). In this approach we can factor in the overheads of TLS session establishment as a one-off cost that is spread across multiple queries and gain the benefit of reliable and secure communications with the recursive server. The server incurs some level of additional overhead in moving from a stateless responder architecture to a session-based system, but we seem to have managed this in the world of HTTPS, and perhaps the incremental cost of session state in the server is not that forbidding.

One view is that most of the DNS server side dimensioning is not based on normal query load in any case, but based on the anticipation of DDOS attack. The capacity of a server includes the consideration of having sufficient capacity to absorb the hostile query traffic and continue to provide responses to non-hostile queries at the same time. With a change from the DNS transport from UDP to TCP the attack profile changes, and the capability to undertake UDP source spoofing goes away. Attacks will no doubt still take place, but the attack profile is expected to be reduced significantly with the change to TCP. This implies that the reckoning of the incremental server load to service TLS clients should include some factor of a reduced potential DDOS attack load profile.

But why add HTTP headers to the TLS session? What do we gain in terms of the capability and efficiency of name resolution transactions by taking this further step from DOT to DOH?

Privacy Resilience

DNS over TLS is certainly far more resilient than DNS over UDP to the various attempts to intercept, block and otherwise interfere with the transactions between a stub DNS resolver within an end system and its chosen recursive resolvers. Once a TLS session is established then the client can be assured that third parties cannot interfere with the flow of DNS queries and responses between the client and the recursive resolver. The client can also be assured (to the extent that such assurances are reasonable in the Domain Name PKI world of Certificate Authorities) that the client is actually communicating with the named recursive resolver.

But the use of TCP port 853 as a dedicated port does admit the possibility of third party blocking of DNS over TLS sessions. The use of unencrypted Server Name Indication field (SNI) when setting up the TLS session an observer could determine which recursive resolver is being used by the client.

DOH uses TCP port 443, allowing both Web and DNS transactions to take place within a single HTTP/2 session if the server is set up to handle both forms of service. Again, the SNI field, if unencrypted, does reveal to third party eavesdroppers the domain name of the DOH service used by the client. However, while a filter on TCP port 853 would block DNS over TLS without necessarily impacting on content services, the same may not be feasible with DOH. Techniques that combine DOH services with web services, as used by some Content Distribution Service providers already, would mean that attempts to block DOH traffic without impacting on potentially unrelated content would be far more challenging.

Pull vs Push

The current architecture of the DNS is one that is uncoupled from other application transactions. An application learns of a service name through some application or user interaction and then has to pass this name to a local DNS stub resolver for the translation of the name into a service address. The DNS itself is a “pull” response model, in that the DNS finds it difficult to anticipate the future name resolution requirements of an application. It’s true that a diligent and highly attentive application could scan its incoming data stream, identify references to service names that will require DNS resolution, and commence the DNS queries immediately via its local DNS query sub-system. HTTP contains server push as well as user pull.

Can we utilize this by embedding the DOH URI into the web object as a push object? It would certainly be faster as the query is being provided before the client application makes an explicit DNS request. And if the resolved DOH object also included a DNSSEC chain response (RFC 7901) then the client could validate the proffered DNS data without having to make a DNS query at all!

Pandering to the Paranoid Application

Applications these days do not necessarily make extensive use of the library provided by the underlying host platform. An admittedly somewhat paranoid view of privacy would attempt to protect an application’s activity not only from potential eavesdroppers in the network, but also from potential eavesdroppers sitting on the same host platform as the application. If a browser really wanted to keep your browsing activity a secret, then it makes sense to avoid using the platform’s DNS services and instead channel the DNS requests back to a trusted resolver across an open HTTPS session.

DOH and Name Spaces

DOH raises an interesting question about visibility of names and the scope of the DNS name space.

There is a general assumption in the DNS that name space is uniformly available. If a URL works for you then you can pass this URL to me with the expectation that I will connect to the same content or service if I use this URL. The way we support this assumption is to set up name servers as promiscuous servers, where a server will respond to all queries in a similar manner, irrespective of who is making the query. This general observation is not quite the case when the DNS is used in content steering contexts, where the DNS response handed out by an authoritative server based on the server’s assumption about the location of the client requesting name resolution. But notwithstanding the way in which answers are generated, the expectation is that names in the DNS are intended to be universally visible, and the name space is uniformly available.

However, a name may be defined within a web object that performs DOH-style push to clients does not need to have a counterpart in the query-based DNS as we understand it. If the name is signed with DNSSEC, there is no need to provide authenticated denial of existence, so there is no requirement to provide NSEC records for these server-pushed names. On the assumption that the only way to “see” that such a name exists is via this push mechanism within the HTTP space then a parallel conventional query-based DNS could provide a different definition of the same name, or even deny its existence. As long as the client application, such as a browser, uses DOH-pushed names solely in the context of the application then the client may be able to maintain the distinction between DNS names learned by explicit query to the DNS and application-context DNS names that were learned buy DOH-push. Why would anyone do this? With this approach each web page is capable of constructing a local name space that is essentially defined by that web page, and names can be ‘bound’ to that web context and may not be accessible via a general DNS query.

For some this may well look like a completely novel approach to naming, where names defined by DOH are tied into a referential context and do not necessarily exist outside that context. It challenges the characterization of the DNS as a single unified and uniform namespace as it allows the creation of private branching within the name space.

After more than twenty years of experience with the DNS we are probably justified in concluding that the remains a significant population of users that do not really like hierarchical namespaces. Not only have we seen many country code domains ‘flatten’ their namespace and allow direct registrations as second level names under the country code, but the same pressures to flatten the name space exist in the root zone itself. The ongoing rounds of release of generic TLDs in the root zone of the DNS space is proving that such releases of new names in the root zone make little inroad into the vast ocean of latent demand.

The enforced hierarchy was seen as a consequence of a single unified name space. Are we seeing in DOH the emergence of the possibility of a rather strange multiverse of name spaces, each defined by the encompassing web object and its embedded push DOH objects? If we were to go further and allow the web object to define itself as the root of trust in the names delivered by the web object and allow us to push DNSSEC chains that point to this trust point, then indeed the mythical nirvana of a flattened, yet extensively partitioned name space could be possible.

But perhaps our flight of fancy has gone too far into areas of DNS heresy with these thoughts. Even if we don’t head into these areas of segmented flattened name spaces, there is still enormous potential value in DOH.

Why DOH?

There is some enormous value in the areas of enhanced privacy where the names being resolved are resolved without necessarily asking the public DNS resolution infrastructure, and DOH certainly can help in achieving this in certain situations.

DOH can simplify client systems. Crafting content delivery and name resolution into a single mechanism can certainly further the agenda of pushing the entire Internet through the eye of the TCP Port 443 needle. But it’s more than that. If we consider environments that push complexity and functionality back into the server, and thereby permit simple transactional clients that have a bare minimum of functionality, then DOH is certainly useful.

There is value in pushing this information directly from the content server to the client application along a secured channel that is intended to be impervious to outside observation or manipulation.

There is value in using a TCP channel that does not have the issues with UDP fragmentation and truncation that we see in the DNS today.

DOH is certainly useful in all these areas.

But for me the real value of DOH lies in the simple observation that pre-provisioning is far faster than post-provisioning. In a delay sensitive environment there is considerable value in shaving delay off the DNS resolution times. A sure way to achieve this is by pre-provisioning the end user application with the resolution outcomes of names that the content server knows will be referenced in the delivered content. This ability to perform DNS name resolution as a push function embedded within content is what makes DOH worthy of attention above and beyond the privacy and robustness arguments that are largely shared by DOT and DOH.

Experimenting with DOH

The Mozilla Firefox browser has recently announced support for DOH. This will allow the browser to use DOH in a number of modes, including running in parallel with conventional queries, running as a first preference for queries and using a conventional query as a fallback in the case of failure, or running DOH exclusively. DOH servers that can be configured with Firefox are available from a number of public DNS resolver services, including Cloudflare (https://developers.cloudflare.com/1.1.1.1/dns-over-https/wireformat/) and Google (https://dns.google.com).

Cloudflare have also released a DOH client, which sets up a local DNS listener and passes all queries to Cloudflare’s 1.1.1.1 DNS service over HTTPS as per the DOH specification. In this way all your local system’s DNS queries and responses can be configured such that the external view is an encrypted packet stream using TCP port 443.

APNIC

Labs

Javascript is disabled