The resolution of domain names and the control of TCP ports are two pillars of network security policy. Since the implementation of the European implementing regulation 2024/2690 on July 1, 2025, DNS providers, top-level domain registries, and cloud services are subject to specific technical requirements. This regulatory framework significantly changes how network teams must approach DNS filtering and TCP flow governance.
Encrypted DNS and loss of network visibility: an underestimated blind spot
DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC protect the privacy of queries between the client machine and the resolver. This protection has a downside: when a browser or operating system uses an external resolver not controlled by the organization, internal filtering policies become ineffective.
The issue is not limited to bypassing block lists. An external resolver can also prevent the detection of data exfiltration via DNS tunneling, a technique that encodes information within the queries themselves. Without visibility into these flows, security teams lose a detection capability that relied on analyzing clear DNS traffic on port 53.
To maintain this visibility, encrypted resolution must be centralized to an internal resolver compatible with DoH or DoT. Security resources on Open Syd detail the associated hardening mechanisms. Firewall-level filtering must then block outgoing DNS queries to unauthorized third-party resolvers, including on port 443 used by DoH.
TCP ports and DNS filtering: building a coherent control policy
DNS primarily uses UDP port 53 for standard queries. When the response exceeds the maximum size of a UDP datagram (512 bytes by default), the server indicates truncation and the client switches to TCP port 53 to obtain the complete response. Zone transfers between DNS servers also use TCP 53.
This UDP/TCP duality creates a specific attack surface. Blocking TCP 53 outbound indiscriminately can break the resolution of certain large records (DNSSEC, long TXT records). Conversely, leaving TCP 53 open without restrictions facilitates DNS tunneling and unauthorized zone transfers.
Criteria for appropriate network filtering
- Allow TCP 53 only between internal DNS servers and identified upstream resolvers, never directly from workstations
- Restrict ephemeral source ports (range 49152-65535 according to IANA recommendations) to legitimate DNS resolution processes via application firewall rules
- Monitor abnormal volumes of outgoing DNS queries, a classic indicator of tunneling or communication with a command and control (C2) server
- Log DNS queries on the internal resolver to feed the SIEM, compensating for the loss of visibility related to end-to-end encryption
Port filtering alone is not sufficient. The combination of port control and DNS content analysis (inspection of resolved domain names, detection of high entropy in subdomains) offers more robust coverage against evasion techniques.
NIS2 obligations: what the directive changes for DNS management
The NIS2 directive (Directive (EU) 2022/2555) and its implementing regulation 2024/2690 introduce operational obligations that directly affect the DNS infrastructure of the entities concerned.
In the event of an incident affecting the availability or integrity of the DNS service, the notification mechanism imposes an initial alert within 24 hours, followed by a detailed notification within 72 hours, and then a final report within one month. These timelines assume a rapid detection and qualification capability for DNS incidents.
The regulation also covers supply chain security, cryptography, and access control. For a network administrator, this means that the choice of an external DNS resolver (cloud service, public resolver) must include an evaluation of the provider against these criteria. Field feedback varies on this point: some organizations believe that large public resolvers offer superior resilience, while others feel that dependence on a third party increases regulatory risk.
Network segmentation and DNS: reducing the attack surface through routing
Network segmentation limits the spread of a compromise, but its interaction with DNS is rarely addressed in detail. A network segmented into VLANs with a single DNS resolver for all segments offers a pivot point for an attacker who compromises that resolver.
Deploying dedicated DNS resolvers by network segment reduces this risk. Each resolver only resolves the names necessary for the segment it serves, and firewall rules prohibit unauthorized inter-segment DNS queries. This approach increases administrative overhead but effectively compartments lateral movements.
Checklist for a DNS audit
- Verify that each network segment has explicit rules allowing or denying DNS traffic to specific destinations
- Ensure that internal DNS records (private zones) are not accessible from segments exposed to the internet
- Control that zone transfers (AXFR/IXFR) are restricted to only authorized secondary servers, with TSIG authentication
The interplay between DNS, TCP ports, and network segmentation forms a coherent set where each component compensates for the limitations of the others. Port filtering without DNS governance remains permeable, just as a secured DNS loses its effectiveness if network routing allows bypasses. The NIS2 directive pushes organizations to formalize this interplay, but the available data does not yet allow for measuring the actual level of compliance achieved by the entities concerned.
