Which port does DNS use? Port 53, and when it is not

What port does DNS use for an ordinary lookup?

A normal query, the kind your browser sends dozens of times a minute, goes out as a single UDP packet to port 53 and comes back the same way. RFC 1035 calls UDP "the recommended method for standard queries in the Internet" because it needs no handshake: one packet out, one packet back, done. That is also why DNS feels instant when it works and why a single dropped packet is enough to make it feel broken, since UDP does not automatically retry for you. The resolver software on your device or router handles the retry, usually against a second configured server if the first stays silent.

When does DNS use TCP instead?

Two situations push a DNS exchange onto TCP port 53. The first is a zone transfer, where a secondary nameserver pulls a complete copy of a zone from the primary. RFC 1035 is explicit that "UDP is not acceptable for zone transfers" because the operation needs a reliable, ordered stream, not a single best-effort packet. The second is a response that will not fit in the UDP message size in use. When that happens, the server sends back a truncated UDP packet with the TC (truncated) bit set, and a compliant resolver notices the bit and re-sends the same query over TCP to get the full answer. You can force that behavior yourself and see the full response directly:

dig +tcp example.com

Everyday queries rarely need this path, but it exists specifically so that DNS keeps working when an answer grows past what a single UDP packet can hold, which happens more often than it used to.

What was the 512-byte limit, and what changed it?

RFC 1035 fixed the UDP message size at 512 bytes, header included, not counting the IP or UDP headers themselves. That number was generous in 1987, when a DNS answer was a handful of address records. It stopped being generous once DNSSEC signatures, longer hostnames and records with many IP addresses became normal, because a signed answer with an RRSIG record routinely runs past 512 bytes on its own.

RFC 6891, published in 2013, fixed the ceiling without touching the wire protocol: EDNS0 adds an OPT pseudo-record that lets a resolver advertise "the largest UDP payload that can be reassembled and delivered in the requestor's network stack," and the RFC suggests 4096 bytes as a practical starting point. A resolver and server that both support EDNS0 can exchange answers several times the old 512-byte cap over a single UDP packet, and only fall back to TCP when even that larger allowance is not enough. Almost every resolver in use today, including your operating system's own, speaks EDNS0 by default, so this upgrade already happened without any action from you.

Why firewalls that allow only UDP 53 cause real problems

A firewall rule written years ago and never revisited often reads "allow UDP port 53, deny everything else DNS-related." That rule blocks the TCP fallback the protocol needs, and the failure it produces is easy to misdiagnose because most lookups keep working fine. Only the ones that grow past the UDP limit fail, and they fail in a way that looks random: a domain resolves normally most of the time and then times out, particularly once DNSSEC validation is involved, since a validating resolver has to fetch the RRSIG and DNSKEY records alongside the answer it asked for.

The practical result is that DNSSEC-signed zones and any record set with many values (a domain with a dozen mail servers, for instance) become unreliable behind a UDP-only firewall, while everything else looks healthy. Blocking TCP 53 outbound, or blocking it in only one direction, is one of the more common self-inflicted DNS outages, and it rarely shows up in a basic connectivity check because that check usually only tries UDP.

DNS over TLS and DNS over HTTPS: different ports, same lookups

Two newer transports carry the same DNS queries and answers but move them off port 53 entirely. DNS over TLS, defined in RFC 7858, wraps each query in a TLS session on TCP port 853, chosen so a network operator can still see that DoT is happening (and block it) even without decrypting it, since the port itself is a clear signal.

DNS over HTTPS, defined in RFC 8484, goes further. It sends DNS queries as ordinary HTTPS requests on port 443, the same port as every other website you visit, and the RFC calls out "the ability to mix DoH traffic with other HTTPS traffic on the same connection" as a deliberate property. That is the whole point of DoH: a network that only inspects or filters by port cannot separate a DNS lookup from any other HTTPS request, because they are the same protocol on the same port. Chrome, Firefox and Edge can all send DNS this way by default now, which is why blocking "port 53" on a network no longer guarantees you have blocked DNS. It guarantees you have blocked the classic transport; a browser with DoH enabled keeps resolving names over 443 regardless.

What is mDNS on port 5353?

Multicast DNS is a different protocol wearing a similar name. RFC 6762 defines it as devices "sending DNS-like UDP query and response messages over IP Multicast to UDP port 5353," addressed to the multicast group 224.0.0.251 (or its IPv6 equivalent, FF02::FB) rather than to a specific server. There is no central nameserver involved at all: every device on the local network segment listens on port 5353 and answers for its own name. This is how a printer or a smart speaker becomes reachable as device.local without anyone configuring a DNS record for it. It is confined to the local link by design and has nothing to do with resolving a public domain name, so mDNS traffic never needs to leave your router.

How to test whether port 53 is reachable

Start with a direct query against a known-good resolver, which tells you whether ordinary UDP lookups work at all:

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

If that succeeds but you suspect the TCP fallback path is blocked, force TCP and compare:

dig +tcp example.com @1.1.1.1

A UDP query that succeeds while the forced-TCP version times out is a strong sign that something between you and the resolver is dropping TCP 53 specifically, the exact failure mode described above. Testing raw port reachability from outside your own network is where our port check tool is useful: point it at port 53 on your resolver or nameserver and it opens a real TCP connection from another network, confirming whether TCP 53 is reachable at all. Read the result with one caveat in mind: a port checker tests TCP, so a pass there confirms the fallback path is open but says nothing about UDP, which has no handshake to test the same way. For the query itself, including comparing answers from multiple public resolvers and different regions at once, run the DNS query tool.

Frequently asked questions

Do I need to open TCP 53 as well as UDP 53?

Yes, for outbound resolver traffic. A firewall that only permits UDP 53 will handle most queries fine and then fail unpredictably on larger, typically DNSSEC-signed, answers that need the TCP fallback.

Does blocking port 53 stop all DNS traffic?

Not anymore. It blocks the classic UDP/TCP transport. DNS over HTTPS runs on port 443 and looks like any other HTTPS request, and DNS over TLS runs on its own port 853, so a browser or app with either enabled keeps resolving names.

Is DNS over HTTPS the same protocol as regular DNS?

The queries and answers are the same DNS records and codes defined by RFC 1035. Only the transport changes: instead of a raw UDP or TCP packet on port 53, the same request is wrapped inside an HTTPS request on port 443.

Why does dig sometimes use TCP without being told to?

When a UDP response comes back truncated, with the TC bit set, a standards-compliant client automatically re-sends the query over TCP to get the complete answer. You see this most often on domains with DNSSEC enabled or many records of the same type.

Is mDNS on port 5353 the same as my ISP's DNS?

No. mDNS only works on your local network segment, has no central server, and resolves names like device.local for devices on the same link. It has no involvement in resolving a public domain such as example.com.

What is a normal EDNS0 payload size today?

RFC 6891 suggests 4096 bytes as a practical default, and most current resolvers advertise something in that range, well above the original 512-byte ceiling, before falling back to TCP only when even that is not enough.