A Security Practitioner's Guide to Encrypted DNS

A Security Practitioner's Guide to Encrypted DNS
Best practices for a shifting visibility landscape.

The Domain Name System, or DNS, is the Internet's directory system. It points you where you want to go, mapping human-readable names like darkreading.com to machine-routable addresses such as 104.17.120.99.


The original DNS protocol, however, is fundamentally insecure. Among other issues, the cleartext nature of the DNS protocol means that attackers with network access can intercept DNS queries to spy on your activity or forge responses to send you to a site where you don't want to go, such as a phishing page or an exploit kit. The security community has made a few efforts to encrypt DNS traffic to address this issue, the latest of which are DNS over HTTPS (DoH) and DNS over TLS (DoT).


Adversaries leverage the DNS system like everyone else. Instead of hardcoding IP addresses for their command-and-control infrastructure, they often leverage purpose-specific domains to allow them to shift traffic as it suits their needs. Because of this, teams often want to monitor DNS traffic for threat intelligence hits, log it, and "sinkhole" domains (rewrite responses) for incident response purposes — the very behaviors that encrypted DNS is intended to prevent.


As encrypted DNS rolls out to end users, security teams' usual toolkits for incident response will no longer work for users encrypting their DNS traffic end to end. Security teams are left with the choice of blocking all encrypted DNS (which removes the protections from encryption) or letting it pass and allowing unmonitored and uncontrolled DNS traffic to flow through their networks. Blocking traffic can cause tension between end users and security team members.


With DoT, DNS queries and answers are conducted directly using Transport Layer Security (TLS). Because public DNS over TLS resolvers use a distinct port (853), se ..

Support the originator by clicking the read the rest link below.