The DNS resolution and TCP port management represent two layers of security often treated separately in corporate network policies. The separation of these two subjects creates exploitable blind spots: a firewall may correctly filter port 53 while allowing DNS requests encapsulated in HTTPS traffic on port 443. Understanding how these mechanisms interact allows for hardening the network configuration without multiplying tools.
Encrypted DNS on port 443: the flaw that traditional filtering does not see
Traditional DNS filtering relies on inspecting traffic passing through UDP/53 or TCP/53. This approach worked as long as DNS requests were transmitted in clear text over a dedicated channel.
DNS-over-HTTPS (DoH), transported over TCP port 443, changes the game. DNS requests are encapsulated in standard HTTPS traffic, making them indistinguishable from the rest of web browsing for a firewall configured solely based on port numbers. DNS-over-TLS (DoT), which typically uses TCP port 853, poses a similar problem but remains easier to identify and block.
According to recommendations shared by CISA and Axio Networks, an effective DNS filtering policy must now enforce authorized resolvers on each endpoint, including browsers that enable DoH by default. It is no longer sufficient to monitor port 53: outbound connections to ports 443 and 853 must also be controlled to detect unauthorized DNS resolutions.
You will find technical information on Open Syd that details the hardening mechanisms applicable to these configurations.
TCP port 53 and firewalls: why blocking TCP causes DNS outages
A common mistake in firewall configuration is to allow only UDP traffic on port 53 while blocking TCP/53. The logic seems reasonable: the vast majority of common DNS requests use UDP.
In practice, TCP/53 is necessary for large DNS responses. DNSSEC records, which add cryptographic signatures to responses, regularly exceed the UDP packet size limit. Zone transfers between authoritative DNS servers also exclusively use TCP. Blocking this protocol on port 53 causes intermittent outages that are difficult to diagnose, as they only manifest for certain types of requests or specific domains.
Cisco’s documentation on DNS prerequisites for Cisco Secure Access distinguishes three network roles, each requiring different firewall rules on port 53:
- The client machine, which sends requests to the internal recursive resolver, can generally limit itself to UDP/53 in most cases
- The recursive resolver must be able to send and receive TCP/53 and UDP/53 to authoritative servers, or it will fail to resolve DNSSEC-signed records
- The authoritative server requires TCP/53 open for zone transfers and large responses
Applying a uniform rule to these three roles weakens name resolution or opens unnecessary channels.
Network security policy: going beyond port number filtering
Port 443 is no longer a reliable indicator of typical web usage. DoH passes through it, but so do VPN tunnels, proprietary application streams, and some DNS security solutions themselves. A strategy based solely on port numbers allows unidentified traffic to pass through.
A more robust approach combines several control parameters:
- Identifying authorized DNS resolvers by their IP address, blocking any other resolvers on ports 53, 443, and 853
- Inspecting TLS certificates to distinguish legitimate DoH from standard web traffic on port 443
- Application monitoring that identifies the actual protocol regardless of the port used, allowing detection of a DNS tunnel encapsulated in HTTPS
- Controlling browser configuration settings to prevent automatic activation of DoH to external resolvers
This logic of defense in depth requires treating DNS not as an isolated service but as a transversal component of the information system. Routing rules, management of applications installed on endpoints, and operating system configuration all contribute to the company’s DNS posture.
DNS monitoring and detection of abnormal flows on the network
Strengthening firewall rules only addresses part of the problem. A compromised internal DNS resolver, or malware that uses DNS as a data exfiltration channel, can generate traffic that complies with filtering rules while being malicious.
Monitoring the volume and frequency of DNS requests is a necessary complement. A machine that issues several thousand requests to the same domain within a few minutes exhibits atypical behavior that warrants investigation. Similarly, requests to high-entropy domain names (random character strings) often signal a DNS tunnel or communication with a command and control server.
Field reports vary on the threshold at which these alerts become actionable without generating too many false positives. The size of the network, the number of endpoints, and the diversity of business applications directly influence the calibration. A poorly calibrated DNS monitoring system generates noise that ends up being ignored by security teams.
The correlation between DNS logs and firewall logs (open TCP ports, unusual outbound connections) helps reduce this noise. A spike in DNS requests to an unknown domain, combined with an outbound TCP connection on a non-standard port from the same machine, produces a much more reliable alert than an isolated indicator.
Hardening DNS and mastering TCP ports are not two separate projects. Available data shows that recent attacks specifically exploit the junction between these two layers, where encrypted DNS traverses ports considered safe. Addressing these issues together, in a unified network security policy, remains the only approach that takes into account the reality of current traffic.
