Port 53 – DNS (Domain Name System)

Port 53 is the default port for DNS, the Domain Name System that turns names like example.com into IP addresses. Almost every query runs over UDP, and DNS falls back to TCP for responses too big for a single datagram and for zone transfers. Because name resolution underpins nearly every other service, an open port 53 both marks a live resolver or authoritative server and hands you a protocol that leaks internal structure, can be turned into a DDoS amplifier, and has a long history of remote-exploitable server bugs.

Why It’s Open

Two different roles both listen on 53. Authoritative servers answer for the zones they own — the MX, NS, and A records that make a domain reachable — so anything hosting DNS for a public domain is legitimately internet-facing on 53. Resolvers take queries from clients and walk the DNS tree to answer them; those should sit inside a network, not on the public internet. You’ll find BIND, Unbound, PowerDNS, and Knot on UNIX, dnsmasq on routers and small networks, and Windows DNS Server on every Active Directory domain controller (where 53 sits alongside Kerberos on 88 and LDAP on 389).

The finding that matters most is a resolver answering recursive queries from the outside. An open recursive resolver on the public internet is both an information leak and the raw material for amplification attacks — usually it’s a dnsmasq on a CPE device or a misconfigured BIND that was never locked to an internal ACL.

Common Risks

• Zone transfer (AXFR). An authoritative server that allows unrestricted AXFR will hand you its entire zone — every hostname, internal IP, mail server, and subdomain in one request. It’s the fastest way to map an organization’s estate, and it needs no exploit, just a misconfiguration.
• DNS amplification / reflection. A short spoofed query to an open resolver (an ANY request, or a large DNSSEC-signed record) returns a response many times bigger, aimed at the victim whose address you forged. Open port 53 resolvers are the ammunition for some of the largest DDoS attacks on record.
• Cache poisoning. If a resolver uses predictable query IDs or source ports, an attacker can race a forged answer into its cache and redirect traffic for a domain — the Kaminsky class of attack (CVE-2008-1447).
• Subdomain and infrastructure disclosure. Even without AXFR, brute-forcing names and reading NS/MX/TXT records exposes internal hosts, cloud providers, and mail routing.
• Server version disclosure. A version.bind CHAOS query often returns the exact BIND build, mapping straight to known CVEs.
• Remote code execution and DoS in the server. BIND and Windows DNS have shipped wormable, pre-auth bugs reachable purely by sending DNS on port 53 (see CVEs below).

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Check if it’s open and read the server info

nmap -sU -sT -p 53 -sV --script=dns-nsid,dns-recursion <target>

dns-recursion tells you whether the server will resolve arbitrary names for you (open resolver); dns-nsid and -sV pull the server identity and version.

Grab the server version directly

dig @<target> CHAOS TXT version.bind
dig @<target> CHAOS TXT hostname.bind

Attempt a zone transfer

dig axfr @<target> example.com

If the server responds with the full record set instead of Transfer failed, AXFR is open — capture the whole zone. Automate discovery of the nameservers and transfer attempts with dnsrecon and dnsenum:

dnsrecon -d example.com -t axfr
dnsenum example.com

Test for an open recursive resolver

dig @<target> google.com A +short

A valid answer for a domain the server isn’t authoritative for means it’s resolving recursively for anyone — flag it as an open resolver and an amplification risk.

Brute-force subdomains

dnsrecon -d example.com -D /usr/share/wordlists/subdomains.txt -t brt
fierce --domain example.com

Metasploit modules

msfconsole -q
use auxiliary/gather/enum_dns
set DOMAIN example.com
set NS <target>
run

use auxiliary/scanner/dns/dns_amp
set RHOSTS <target>
run

enum_dns sweeps records and attempts AXFR; dns_amp measures the amplification factor so you can prove the reflection risk in the report.

Record every open resolver, successful zone transfer, and disclosed version as you confirm it, so the findings land in the pentest report with the exact dig output attached instead of scrolling out of your terminal.

What to Look For

Known CVEs and Exploits

• CVE-2020-1350 — “SIGRed.” A 17-year-old heap overflow in Windows DNS Server, reachable by a crafted response to a SIG record query. Wormable, pre-auth, CVSS 10.0, and able to spread between domain controllers without user interaction. Proof-of-concept code is public on Exploit-DB.
• CVE-2015-5477 — An assertion failure in ISC BIND lets a remote attacker crash named (denial of service) with a single crafted TKEY query. Trivial to trigger and weaponised as the Metasploit module auxiliary/dos/dns/bind_tkey.
• CVE-2023-50387 — “KeyTrap.” A design flaw in DNSSEC validation lets one malicious response force a resolver into enough signature checks to exhaust its CPU, stalling BIND, Unbound, PowerDNS, and Knot. A single packet can take a resolver offline.
• CVE-2008-1447 — The Kaminsky cache-poisoning flaw. Insufficient randomization of query IDs and source ports let an attacker inject forged records into a resolver’s cache and hijack a domain. It triggered a coordinated multi-vendor patch of the entire DNS ecosystem in 2008.

Mitigation

• Restrict zone transfers. Limit AXFR to known secondaries with allow-transfer { ...; }; in BIND (or the equivalent), and default it to none.
• Disable open recursion. Split authoritative and resolver roles; on resolvers, bind recursion to internal clients only (allow-recursion) so the server never answers the public internet.
• Rate-limit responses. Enable Response Rate Limiting (RRL) to blunt amplification and reduce the value of the server as a reflector.
• Source-port and query-ID randomization + DNSSEC. Keep the server patched so it randomizes ports and IDs (the Kaminsky fix), and validate DNSSEC where appropriate to prevent poisoning.
• Hide the version. Set version "not disclosed"; in BIND so version.bind stops advertising a CVE.
• Patch promptly. SIGRed, KeyTrap, and the TKEY DoS were all fixed upstream before mass exploitation — a current build closes them.
• Firewall port 53. Expose it only on the hosts that must answer publicly (authoritative servers), and keep resolvers off the internet entirely.

Real-World Example

In July 2020, Microsoft patched CVE-2020-1350 (SIGRed), a wormable remote-code-execution bug that had sat in Windows DNS Server for 17 years. Because DNS runs on every Active Directory domain controller, a single crafted response on port 53 could execute code as SYSTEM and spread machine to machine without a user ever clicking anything — the kind of flaw that turns one exposed resolver into a domain-wide compromise. The U.S. government issued an emergency directive giving agencies a day to patch. It’s the clearest reminder that port 53 isn’t just an information leak: the server behind it is remote-attack surface.

FAQ

What is port 53 used for?

Port 53 is the default port for DNS — the system that resolves domain names to IP addresses. Resolvers and authoritative name servers both listen on it, using UDP for ordinary lookups and TCP for zone transfers and large responses. Nearly every internet connection begins with a DNS query on port 53.

Is port 53 TCP or UDP?

Both. DNS uses UDP 53 for standard queries and responses because it’s fast and connectionless, and falls back to TCP 53 when a response is too large for a single UDP packet (over 512 bytes, or with EDNS) and for zone transfers (AXFR). A properly firewalled DNS server allows both.

Is port 53 dangerous?

The port itself is necessary, but it exposes real risk when misconfigured. An open recursive resolver can be abused for amplification DDoS, an unrestricted zone transfer leaks your whole internal DNS, and an unpatched server (see SIGRed) can be remotely exploited. On an authoritative server it’s expected; a recursive resolver answering the public internet is a finding.

How do I secure port 53?

Restrict zone transfers to known secondaries, disable recursion for external clients, enable response rate limiting, hide the server version, and keep the software patched. Firewall TCP/UDP 53 so only authoritative hosts answer publicly, and keep resolvers internal. Rescan with nmap -sU -sT -p 53 <target> and retest recursion to confirm the fix.

TL;DR

• Service: DNS (Domain Name System)
• Default port: 53/UDP (queries) and 53/TCP (zone transfers, large responses)
• Biggest risk: open recursion (amplification DDoS), unrestricted zone transfer, and server RCE like SIGRed (CVE-2020-1350)
• Mitigation: restrict AXFR, disable open recursion, rate-limit, hide version, patch, firewall to authoritative hosts