The following is a quick write-up I presented to my senior leadership regarding DNS over TLS. It was rooted in the mistake presumption that Google was going to “enforce DNS-over-TLS”. In short. Interestingly, this system is currently in use by Android, but I do not believe this will ever attain mainstream adaptation.
High Level Summary
DNS over TLS is a 2016 protocol that allows clients to resolve a hostname over the HTTPS (TLS) protocol. The client will issue a GET request specifying the hostname and request type and the server will respond with the requested data in JSON. All requests are over TCP/853.
The implementation of DNS over TLS is in the user-space resolution libraries and should not may even be unnoticed by user-land application. From a security perspective, this has a noticeable but easily manageable security impact around TLS security and allowing traffic over port 853.
Except for Android, currently no major operating system natively supports DNS over TLS. I do not foresee this protocol gaining mass implementation nor do I see Google’s public DNS servers mandating it for all clients.
Relation to DNSSEC
DNSSEC and DNS over TLS are parallel features of the DNS protocol. DNSSEC is a DNS protocol extension that provides integrity, but fails to provide confidentiality. As such, a Man-in-the-Middle (MitM) attacker could identify potential endpoints or targets. The DNS over TLS protocol provides both integrity and confidentiality, independent of DNSSEC. Additionally, the DNS over TLS client and server does not communicate over the DNS protocol.
There are three (3) broad security implications from implementing DNS over TLS. These implications are specific to TLS, not DNS over TLS.
FIPS 140-2 Encryption Module
The FIPS 140-2 publication is a recommended standard for encrypted modules. As such, any encryption on government IT systems are subject to this standard. In the case of DNS-over-TLS, this must be through an approved encryption module, most typically OpenSSL.
TLS is not an encryption cipher. TLS is a protocol that provides three aspects of protection: Authentication via a certificate or user certificate, an encryption cipher and hashing mechanism.
Any implementation of TLS over DNS would have to ensure that the TLS version is free from publicly known or feasible attacks. The current version of TLS is revision 1.2, with TLS 1.3 in draft format. All versions of TLS below 1.1 and all versions of Secure Socket Layer (SSL) are vulnerable to various attacks, namely POODLE and ORACLE.
Proper TLS implementations typically utilize a certificate signed by a trusted certificate authorities. In the case of DNS-over-TLS, this requires additional dependence on the certificate authorities for every resolution. This may not be a problem for an end-user who trusts commonly trusted root-level certificate authorities. However, root-level certificates are often subject to distrust or influence from hostile state actors and high-secure environments should not blindly trust the decision of Microsoft or Redhat.
Encryption Cipher and Hashing Mechanism
TLS is a mechanism to facilitate encryption over a network and the hashing algorithm provides data verification. Both encryption ciphers and hashing mechanisms are in slow flux and should be closely followed. For example, in 2015 numerous agencies and security researchers reported that they could compromise RC4 cipher. Google Security researchers reported that they can perform a collision attack against the SHA1 hashing algorithm. Both algorithms were widely implemented in the industry.
A TLS connection initialization is computationally expensive. Therefore, the RFC suggests that the client maintain an indefinite open TCP connection over port 853. This may require an additional firewall rule to the DNS server.
The DNS over TLS protocol was formalized in 2016. Due to its relatively young age, currently there are currently very few implementations.
As the RFC documentation specifies, DNS over TLS should be implemented at the host resolution library level, particularly the getaddrinfo(3) and gethostbyname(3) functions. As such, the operating system only needs to maintain library ABI compatibility, but the application does not need implement anything. Currently, only the Android operating system has implemented DNS over TLS while some Linux user-land tools can perform DNS over TLS resolutions.
Google has currently implements DNS over TLS on 184.108.40.206, 220.127.116.11, 2001:4860:4860::8888 and 2001:4860:4860::8844. Google also offers a web-interface which submits a JSON GET request.
For example, to URL https://dns.google.com/resolve?name=farhan.codes would resolve the hostname farhan.codes. The formatted response is as follows:
Standard Implementation Method
There are several implementations of DNS over TLS encapsulated in simplified Docker containers. In summary, the containers utilize a standard web server to handle the HTTP layer and communicates to the DNS server over the DNS protocol. This is a standard method of isolating the HTTP layer from the application layer.
I do not believe that the DNS over TLS protocol will attain mass implementation, nor that Google will mandate it for use of their DNS servers. There are three (3) primary reasons why:
- Architecture: Historically, short-term add-ons to a protocol are superseded by permanent change to the protocol or a parallel revision. If the goal is confidentiality, this can be achieved via an extension to the protocol.
- Performance: Per Google research, DNS is a bottleneck when a URL has multiple external sources. However, I suspect the current DNS resolution is still significantly faster. A UDP-based connection requires only a UDP socket with a simple sendto(2) call, whereas DNS over TLS requires multiple layers of conversion across potentially multiple machines. Specifically, from TLS to HTTP across the internet, converted to the DNS server and back across the same route.
- Standardization: There does not appear to be a TLS over DNS standardization. Most implementations utilize HTTP, but this is not specified in the RFC. Additionally, the JSON format differs between the implementations.
This paper is based on multiple sources. The primary sources are cited below.
- DNS-over-TLS, Google Public DNS: https://developers.google.com/speed/public-dns/docs/dns-over-https
- RFC 7858, Specification for DNS over Transport Layer Security (TLS): https://tools.ietf.org/rfc/rfc7858.txt
- DNS Queries over HTTPS: https://tools.ietf.org/html/draft-hoffman-dns-over-http-00
- A Docker container for a DPRIVE server: https://github.com/wkumari/dprive-nginx-bind