Many security teams champion encrypted DNS as a privacy‑preserving feature. The premise is simple: if DNS queries travel over HTTPS, network‑level sensors can’t see which domains are being resolved, and therefore user traffic is less observable. However, the same opacity that protects privacy also blinds defenders. This article explains why deploying DNS‑over‑HTTPS (DoH) across corporate workstations can cripple traditional detection pipelines, and provides a concrete, reproducible method for auditing, disabling, and logging DoH activity on both Linux and Windows platforms.

What the Hidden Cost Looks Like

Threat‑intel platforms typically ingest DNS logs from resolvers, firewalls, or forward‑ers to spot command‑and‑control (C2) traffic, data‑exfiltration attempts, and fast‑flux domains. When a workstation bypasses the corporate resolver and sends DNS over TLS/HTTPS directly to a public provider, those logs disappear. An attacker can therefore hide malicious lookups behind legitimate‑looking HTTPS traffic, evading detection without raising any obvious red flags.

The problem is amplified in environments that rely on DNS‑based indicators of compromise (IoCs) for automated blocking. Once DoH is in the mix, the security operation center (SOC) loses the ability to correlate DNS queries with other telemetry, leading to blind spots exactly where attackers thrive.

Audit: Detecting DoH Clients on the Network

Before you can remediate, you need to know which hosts are already using DoH. The following Bash script scans a subnet for outbound TLS connections on the well‑known DoH ports (443) and matches the Server Name Indication (SNI) against a list of public DoH providers. 

#!/usr/bin/env bash
# audit_doh.sh – Identify hosts that contact known DoH endpoints

declare -a DOH_SNI=(
  "cloudflare-dns.com"
  "dns.google"
  "mozilla.cloudflare-dns.org"
  "dns.quad9.net"
)

SUBNET="10.0.0.0/24"

echo "Scanning $SUBNET for DoH traffic…"

# Use tcpdump to capture the first packet of each TLS handshake
sudo timeout 30 tcpdump -nn -i any -s 0 \
  -w /tmp/doh.pcap \
  'tcp dst port 443 and (tcp[tcpflags] & tcp-syn != 0)'

# Extract SNI values with tshark
tshark -r /tmp/doh.pcap -Y "tls.handshake.extensions_server_name" \
  -T fields -e ip.src -e tls.handshake.extensions_server_name \
  | while read ip sni; do
      for provider in "${DOH_SNI[@]}"; do
        if [[ "$sni" == "$provider" ]]; then
          echo "Host $ip contacts DoH provider $sni"
        fi
      done
    done

Run the script from a privileged host on the same VLAN. Any output indicates a workstation that is already bypassing corporate DNS. Capture the IPs for the next step.

Linux: Disabling System‑Wide DoH in systemd‑resolved

Modern Linux distributions often enable DoH via systemd‑resolved when the DNSOverTLS=yes or DNSOverHTTPS= options appear in /etc/systemd/resolved.conf. To enforce the corporate resolver, replace those settings with explicit DNS servers and restart the service. 

# /etc/systemd/resolved.conf
[Resolve]
# Disable any built‑in DoH/TLS configuration
DNSOverTLS=no
DNSOverHTTPS=no

# Force use of internal resolvers
DNS=10.10.10.1 10.10.10.2
FallbackDNS=1.1.1.1 8.8.8.8

# Optional: log every query for later audit
LogLevel=debug

Apply the changes: 

sudo systemctl restart systemd-resolved
sudo resolvectl flush-caches

Verify that DoH is no longer active by checking the resolver’s status: 

resolvectl status | grep -i "DNSOver"

The output should show DNSOverTLS=no and DNSOverHTTPS=no.

Windows: Removing DoH from the DNS Client

Starting with Windows 10 2004, Microsoft ships a built‑in DoH client that can be toggled via Group Policy or PowerShell. The following PowerShell snippet disables DoH globally and forces the machine to use the configured DNS servers. 

# Disable DoH at the OS level
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\DNSClient" `
  -Name "EnableAutoDoh" -Value 0 -Type DWord

# Verify the setting
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\DNSClient" `
  -Name "EnableAutoDoh"

After applying the registry change, restart the DNS Client service: 

Restart-Service -Name DnsCache

To confirm that no DoH connections are being made, capture network traffic with netsh trace and filter for port 443 connections whose SNI matches known DoH providers: 

# Start a 30‑second capture
netsh trace start capture=yes tracefile=C:\temp\doh.etl maxsize=100

# Wait 30 seconds, then stop
netsh trace stop

# Analyze with Message Analyzer or convert to pcap
netsh trace convert input=C:\temp\doh.etl output=C:\temp\doh.pcap

Logging DNS Queries for Threat Hunting

Once DoH is disabled, re‑enable DNS query logging on the corporate resolver. For BIND, add the following to named.conf: 

logging {
    channel query_log {
        file "/var/log/named/query.log";
        severity info;
        print-time yes;
    };
    category queries { query_log; };
};

For Microsoft DNS, enable debug logging via the DNS Manager UI or PowerShell: 

Set-DnsServerDiagnostics -All $true -LogFilePath "C:\DNS\Logs"

Centralize these logs with a log‑aggregation tool (e.g., Elastic Stack, Splunk, or Loki) and create a detection rule that flags queries to high‑risk domains. The rule can be as simple as a regular expression match: 

# Example Splunk query
index=dns sourcetype=bind_query
| regex query="(?i)(evil|malware|c2)\.example\.com"
| stats count by src_ip, query

Why Not to Rely Solely on Encrypted DNS for Privacy

Encrypted DNS protects against passive eavesdropping on untrusted networks, but it does not replace a well‑designed DNS architecture that includes response policy zones (RPZ), DNSSEC validation, and robust logging. Deploying DoH without these complementary controls gives a false sense of security. Attackers can still exfiltrate data via other channels, while defenders lose a valuable source of intelligence.

Conclusion

The allure of DNS‑over‑HTTPS is understandable, yet the trade‑off between privacy and visibility is often mis‑balanced in corporate settings. By auditing existing DoH usage, forcibly disabling client‑side DoH on Linux and Windows, and re‑establishing comprehensive DNS logging, security teams regain the telemetry necessary to spot malicious activity. The steps outlined above are reproducible, scriptable, and can be rolled out via existing configuration‑management pipelines (Ansible, Chef, or Intune).

Remember: protecting user privacy does not have to come at the expense of threat detection. A disciplined approach that centralises DNS resolution, validates responses, and logs every lookup offers both confidentiality and the visibility required to keep modern enterprises secure.