DNS over TLS (Transport Layer Security) or “DoT” is an IETF standard that provides full-stream encryption between a DNS client and a DNS server. DNS has traditionally suffered from a “last mile” security problem: Communications between a DNS client and the DNS server are almost always unencrypted, and therefore subject to spoofing, interception, and more. DNS over TLS is documented in IETF RFC 7858 — Specification for DNS over Transport Layer Security (TLS).
HOW DNS OVER TLS (DoT) WORKS
Initiation of DNS over TLS is very straightforward. By establishing a connection over a well-known TCP port, 853, clients and servers expect and agree to negotiate a TLS session to secure the channel.
RFC 7858 defines the following method for using DNS over TLS to establish secure sessions:
- Session Initiation. A DNS server that supports DNS over TLS listens for and accepts TCP connections on Port 853, unless it has a mutual agreement with its server to use a different port for DoT. When using DNS over TLS, all TCP connections on Port 853 should be encrypted, as significant security issues arise in mixing encrypted and unencrypted data.
- TLS Handshake and Authentication. Once the DNS client successfully connects, it proceeds with the TLS handshake and will authenticate with the DNS server, if required. After the TLS negotiation is completed, the connection is encrypted.
DNS OVER TLS (DoT) VS DNS OVER HTTPS (DoH)
DNS over HTTPS (DoH) is a second IETF security protocol that addresses DNC client and DNS server communication security. DoH is documented in IETF RFC 8484. Both DNS over TLS and DNS over HTTPS provide for encryption between the DNS client and the DNS server, enabling data privacy and integrity. However, DoH uses the same TCP port used by other HTTP-S traffic, Port 443. As a result, identifying DoH from other HTTP-S traffic can be difficult.
However, DoH has limitations in that some applications that support DoH also may deliberately ignore local DNS client configuration. Mozilla’s Firefox browser, for example, has experimental support for DoH in some builds. When enabled, Firefox will ignore any local DNS configuration and send DNS queries over HTTP-S directly to Cloudflare. This bypasses any local security mechanisms, such as RPZs, and makes a user’s DNS resolution opaque to their IT organization. It also adds complexity to troubleshooting DNS problems, as now one application (i.e., Firefox) on a device uses different DNS servers than other applications.
DNSSEC AND DNS OVER TLS (DoT)
DNSSEC, the DNS Security Extensions, add authentication and data integrity checking to DNS, usually misses DNS client: the local DNS server performs DNSSEC validation and establishes the authenticity and integrity of the data, and then passes the result to the DNS client. That last leg of the communication, however, can be spoofed.
IMPLEMENTATION RECOMMENDATIONS FOR DNS OVER TLS (DoT)
Infoblox recommends that companies block direct DNS traffic—including DoT—between internal IP addresses and DNS servers on the Internet, including Cloudflare’s. This prevents certain types of malware, including DNSChanger, from working, and forces internal hosts to use IT-managed DNS infrastructure. That internal DNS infrastructure may apply a name resolution policy using security mechanisms such as Response Policy Zones (RPZs).
Blocking standard DNS and DoT traffic between internal IP addresses is simple. Firewall rules like the following should suffice:
allow tcp/udp in/out <authorized internal DNS server 1> on port 53
deny tcp/udp in/out to all IP addresses on port 53
deny tcp/udp in/out to all IP addresses on port 853
LEARN MORE ABOUT DNS OVER TLS (DoT) AND RELATED TECHNOLOGIES
Infoblox is leading the way to next-level DDI with its Secure Cloud-Managed Network Services. Infoblox brings next-level security, reliability, and automation to on-premises, cloud and hybrid networks, setting customers on a path to a single pane of glass for network management. The recognized industry leader, Infoblox has over 8,000 customers, including 350 of the Fortune 500.