Why DNS Control at the Perimeter Is Non-Negotiable

DNS is not just a lookup service. It is a fully functional, often completely exposed, communication channel that most enterprises still treat like a harmless utility. That mindset gets people burned.

Most networks still allow outbound DNS traffic to any server on the internet. That means a clever script with a bit of base64 encoding can chop a file into segments, stuff each one into the subdomain of a DNS query, and fire it off to a server the attacker controls. The perimeter doesn't blink. The firewall logs show nothing abnormal. And the data walks right out the door.

I built a proof-of-concept in Python that did exactly this. The script broke files into chunks, defined the length and number of segments, and sent them out as DNS queries to a domain I owned. A listener decoded and rebuilt the original file. No proxy evasion. Just pure, dumb DNS. That’s all it takes.

This is why application-level control over DNS is critical. Not just blocking port 53, but enforcing behavior through actual inspection and policy.

Use Your NGFW as a DNS Proxy

Modern NGFW let you terminate DNS requests directly and act as a DNS proxy with some configuration to support it. This allows full inspection of:

• Standard DNS over UDP and TCP (port 53)

• DNS over TLS (DoT, port 853)

• DNS over HTTPS (DoH, port 443)
  

If DNS is not proxied through the firewall and there is no SSL Decryption, visibility is lost the moment clients use encrypted DNS. And they will. Chrome and Windows are already shifting to DoH and DoT by default. There are absolutely caveats to this but the point is the same.

With DNS proxy enabled:

• You can decrypt DNS over TLS because the connection terminates at the firewall

• You can enforce threat detection and block malicious domains using threat intelligence

• You can apply policy based on App-ID instead of relying on ports

• You can log queries, responses, users, devices, and destinations

This is what real control looks like.

Don’t Trust Port-Based Rules

If you’re allowing UDP 53 outbound with a rule labeled “DNS,” that’s not enough.

Use App-ID to enforce DNS behavior. Block all traffic that doesn't match the DNS application signature. This closes the door on:

• DNS-over-HTTP or DoH masquerading on other ports

• Custom tunneling traffic wrapped in fake DNS headers

• Raw UDP packets used as covert channels

  
  

App-ID enforcement means only recognized DNS applications are allowed out. Everything else is denied by default.

DNS Attack Vectors That Are Not Well Known

DNS has more than two dozen attack vectors that are often left unmonitored:

1. DNS tunneling (Iodine, DNScat2)

2. Subdomain-based data exfiltration

3. Command and control over DNS

4. DNS rebinding attacks

5. Domain generation algorithms (DGAs)

6. Fast flux infrastructure

7. Phantom domains

8. Cache poisoning

9. DNS hijacking

10. Spoofed DNS responses

11. NXDOMAIN flooding

12. Subdomain enumeration for recon

13. Amplified DDoS via DNS reflection

14. Typosquatting attacks

15. Wildcard DNS abuse

16. Subdomain takeovers

17. Expired domain hijacks

18. Dangling records in cloud platforms

19. DNSSEC misconfigurations

20. Reflection and replay via open resolvers

21. Split-horizon leakage

22. TXT record command payloads

23. DNS-based malware delivery

24. Abuse of AAAA and CNAME records for covert comms

None of these require exploits. Just misconfigurations and blind spots.

What You Need to Do

• Proxy all DNS through your NGFW

• Block outbound DNS to anything but approved resolvers

• Decrypt and inspect encrypted DNS sessions

• Log and analyze DNS traffic continuously

• Enforce App-ID controls and block non-DNS apps using port 53

• Monitor for abnormal DNS usage and tunneling attempts

Treat DNS as a first-class protocol for both visibility and enforcement. If your firewall isn’t controlling DNS at this level, you’re running it as a router, not a security device.