Port / TCP/UDP
53DNS
DNS resolves names to addresses over UDP for ordinary queries and over TCP for large answers and zone transfers.
If it is internet-facing: Port 53 is legitimate in the right place, but exposed carelessly it widens the attack surface noticeably.
Exposure
Internet-facing
Transport
Cleartext
Risk if public
Elevated
Exposure verdict
Port 53 normally answers from the internet, but the transport is not confidential by default. Enforce the encrypted variant before the traffic leaves your network.
Traffic crosses the network readable and modifiable. Anything sensitive on this port needs a tunnel, a VPN, or a different protocol.
Assigned by IANA through a review process. On Unix systems a process needs root or the CAP_NET_BIND_SERVICE capability to bind here, which is why containers so often remap these to a higher port.
Grouped with the other network services ports so a rule written for one can be checked against its neighbours.
What actually goes wrong
2 notes- A resolver that answers recursive queries for the whole internet will be conscripted into amplification attacks.
- Unrestricted AXFR zone transfers hand an attacker your complete internal naming map.
Recommended firewall rule
Allow it, and harden the service
This port is expected to answer from anywhere, so the firewall is not where its security comes from.
ufw
sudo ufw allow 53/tcp
sudo ufw allow 53/udpiptables
sudo iptables -A INPUT -p tcp --dport 53 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 53 -j ACCEPTCheck what is really there
Listening locally
sudo ss -tulpn 'sport = :53'The bind address is the answer that matters: 127.0.0.1 is local-only, 0.0.0.0 and :: mean every interface.
Listening (macOS)
sudo lsof -nP -iTCP:53 -sTCP:LISTENmacOS ships lsof rather than ss; this names the owning process and user.
From outside
nmap -sSUV -Pn -p 53 <host>A version probe confirms whether DNS is actually what answers, rather than trusting the number. Only scan hosts you are authorised to test.
Reachability
nc -vz <host> 53The quick yes/no when you only need to know whether a path exists through the firewall.
The safer path
no port changeChange the configuration, not the port
DNS over TLS (853) and DNS over HTTPS (443) encrypt the query itself.
The fix here lives in the service configuration rather than in a different port assignment.