The DNS associates a readable domain name with an IP address usable by network devices. TCP ports, on the other hand, determine which services accept or reject an incoming connection. These two mechanisms, often configured once and then forgotten, are nonetheless privileged attack vectors when mismanaged.
DNS Resolution and Attack Surface: What Encryption Changes
By default, DNS queries travel in clear text over UDP port 53. An attacker positioned on the network can intercept these queries, modify them, or redirect traffic to a malicious server. Traditional DNS filtering relies precisely on this visibility: the administrator inspects the queries to block dangerous domains.
The arrival of DNS over HTTPS (DoH) disrupts this balance. DoH encapsulates DNS queries in standard HTTPS traffic, over TCP port 443. The content of the queries becomes invisible to network monitoring tools. A workstation configured to use an external DoH resolver can thus bypass the entire corporate DNS filtering without triggering an alert.
The solution is not to blindly block DoH. The recommended approach is to define an internal authorized DNS resolver, compatible with DoH or DoT (DNS over TLS, port 853), and then enforce its use on workstations via group policies or an MDM.
Queries to unapproved external resolvers are then blocked at the firewall level. This configuration preserves the confidentiality of DNS exchanges while maintaining filtering capability, as detailed in the security guide on Open Syd in its section dedicated to hardening network policies.
Open TCP Ports: Reducing the Exposed Surface of the Network
Each open TCP port on a server represents a potential entry point. A service listening on an unused or unmonitored port provides a direct opportunity for an attacker to attempt a connection, exploit a vulnerability, or establish a command channel.
Identifying the Ports That Are Truly Necessary
The first step is an inventory. Too many environments retain open ports inherited from old configurations: test services, temporary administration interfaces, obsolete protocols. A regular scan of exposed ports from outside the network often reveals services that no one suspected existed.
The ports to monitor as a priority:
- Port 53 (DNS) should be restricted to only authorized internal DNS servers, and outgoing DNS traffic to unapproved external resolvers blocked at the firewall
- Port 443 (HTTPS) deserves special inspection since DoH passes through it, making data exfiltration or circumvention of security policies possible
- Remote administration ports (22 for SSH, 3389 for RDP) should never be exposed directly to the internet without an intermediate gateway or VPN
- Ports associated with legacy services (Telnet on port 23, FTP on port 21) should be disabled in favor of their encrypted equivalents
Applying the Principle of Least Privilege to Network Flows
Each firewall rule should specify a source, a destination, and a specific port. “Any to any” rules on a given port amount to leaving a door open to anyone who knows the address. Network segmentation complements this approach: placing DNS servers in a dedicated segment limits lateral propagation in the event of a compromise.
DNSSEC and DNS Account Protection: Two Complementary Layers
DNSSEC cryptographically signs DNS responses to ensure that the information received by the client corresponds to that published by the legitimate server. Without this validation, an attacker can inject false responses (cache poisoning) and redirect traffic to malicious servers without the user detecting anything.
Implementing DNSSEC remains as much an operational issue as a cryptographic one. Configuration errors, particularly in the rotation of signing keys, can cause service interruptions. Activation therefore requires prior testing and a documented rollback procedure.
An often-overlooked angle concerns the protection of the account that administers the DNS records. Taking control of this account allows for direct modification of DNS responses, redirection of traffic, or generation of fraudulent TLS certificates. The U.S. agency CISA recommends protecting these accesses with multi-factor authentication, regularly auditing published records, and monitoring Certificate Transparency logs for any unauthorized certificate issuance.
NIS2 Directive and DNS Risk Management in Europe
The European NIS2 directive expands the scope of entities subject to cybersecurity obligations. DNS service providers are explicitly among the affected entities. The European implementing regulation 2024/2690 specifies the expected technical requirements, particularly regarding cyber risk management.
For organizations operating their own DNS infrastructure, this regulatory evolution implies formalizing several practices:
- Documenting the DNS zone management policy, including zone transfers and replication mechanisms
- Implementing logging of record changes and access to DNS servers
- Integrating DNS components into the scope of periodic security audits
These requirements are not new from a technical standpoint. NIS2 makes them legally binding, with penalties for non-compliance.
The joint mastery of DNS and TCP ports forms a foundation of network security that neither application firewalls nor antivirus can replace. A properly configured DNS resolver and strictly filtered ports reduce the attack surface even before a detection tool comes into play.
