🔐 DoH, DoT, and Punycode: What Every Forensicator Needs to Know About Modern DNS Evasion Tactics
- 7 minutes ago
- 3 min read
DNS is often referred to as the phonebook of the internet — and traditionally, it’s been fairly easy to read. But as privacy and censorship concerns grew, so did efforts to encrypt DNS traffic, giving us technologies like DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH).
While they offer legitimate security benefits, these methods also pose serious challenges for incident responders and forensic analysts.
=Traditional DNS vs. DoT and DoH
Let’s start with what’s familiar: traditional DNS queries, typically using UDP over port 53. These queries are sent in plaintext, making them easy to observe in tools like Wireshark.
For example, a simple A record lookup for https://www.cyberengage.org/ might be just 32 bytes of DNS payload — and it’s all visible to anyone monitoring the wire.
Now compare that with:
DNS-over-TLS (DoT)
Protocol: DNS traffic over TLS (like HTTPS, but just for DNS).
Port: Default is TCP/853.
Benefit: Encrypts DNS traffic, preventing outsiders from seeing which domains are being queried.
Visibility: Possible to block or detect based on port/protocol — unless the attacker starts tunneling DoT through a different port.
DNS-over-HTTPS (DoH)
Protocol: DNS sent as part of a regular HTTPS request.
Port: TCP/443 — indistinguishable from regular web traffic.
Challenge: Blends perfectly with normal browsing traffic.
Visibility: Basically zero unless you're doing TLS interception, which is controversial and legally risky.
A Closer Look at DoH in Action
DoH can send DNS data in two ways:
POST method: The DNS payload is dropped into the body of the POST request.
GET method: The DNS payload is Base64-encoded and appended as a URL parameter.
In both methods, the transaction ID is set to zero, as per the DoH RFC. This allows DoH responses to be cached, which isn't possible with randomized IDs.
While these may look like regular HTTPS traffic, they’re actually DNS queries in disguise — a huge blind spot if you’re only monitoring port 53.
The Problem with TLS Interception
TLS interception (aka SSL decryption) is the most reliable way to see inside DoH traffic, but let’s be real — it’s tricky and controversial. Here's why:
Technically: It works. Middleboxes decrypt the traffic, inspect it, then re-encrypt and forward it.
Legally: Risky. This is considered intrusive in many regions and can violate privacy laws.
Operationally: Complex. You need tight certificate management, and every endpoint must trust the interceptor.
Because of this, many orgs simply don’t go down this road — even if they’d like to.
Other Detection Options
So how do we detect or control encrypted DNS if we’re not intercepting TLS?
For DoT:
Block or monitor TCP/853.
Use firewall rules to prevent outbound connections on uncommon ports.
Track DNS servers in use and look for rogue ones.
For DoH:
Traffic profiling: Since DoH is just HTTPS, you can analyze traffic behavior (e.g., regular POSTs to dns.google or cloudflare-dns.com).
Control system and app settings: Disable DoH in browsers, OS, and apps where possible. But malware won’t respect your group policies.
Enter Punycode and Internationalized Domain Names (IDNs)
Now let’s throw another wrench into DNS analysis: Punycode, the format used for IDNs (Internationalized Domain Names).
Here’s the problem: DNS was built in an ASCII-only world. As the internet went global, people needed non-English characters in domain names. Enter Punycode — a way to encode Unicode characters using only ASCII.
But here’s where it gets dangerous: visual spoofing.
Example:
Legit domain: wix.com
Spoofed domain: wıx.com (note the Turkish “ı” character instead of “i”)
To the human eye, they look identical. But behind the scenes, the punycode version might be:
Forensic Tip:
Any domain that starts with xn-- is a punycode domain.
Use online tools or Python libraries to decode them and inspect their real intent.
Not every punycode domain is malicious, but they deserve scrutiny, especially in phishing investigations.
Final Thoughts: What You Should Be Doing Now
Encrypted DNS and IDNs aren't going anywhere. They’re part of the modern internet — for better and worse.
Here’s what defenders can do:
Log everything — especially DNS queries, NetFlow, and HTTPS metadata.
Monitor DoH/DoT behavior and block unauthorized resolvers.
Identify punycode domains and decode them during investigations.
Use passive DNS to track patterns over time, detect beaconing, and flag newly seen domains.
Build user and host baselines to catch anomalies in DNS behavior.
Malware authors love DNS because most people don’t watch it closely. But once you start paying attention,
DNS can tell you exactly what your adversaries are doing — you just need the right lens to see it.
--------------------------------------------------Dean-----------------------------------------------