Port 53 is the DNS port, over both UDP and TCP. Ordinary queries use UDP because a question and an answer fit in one packet each. DNS falls back to TCP on the same port when the response is too large, and always uses TCP for zone transfers.
- UDP 53 carries almost every query, one packet each way
- A response too large comes back with only a truncated flag
- The client then repeats the same query over TCP 53
- DNSSEC and IPv6 records made large responses ordinary
- Encrypted DNS moved off 53 entirely: 853 for DoT, 443 for DoH
On this page
Why UDPWhy UDP first
DNS was designed around one insight: a lookup is a single small query with a single small response, and the cost of building a TCP connection for that is larger than the DNS exchange itself.
A TCP connection needs three packets to open, at least two to carry the data, and more to close. A UDP query is one packet out and one packet back. On a DNS server answering thousands of queries a second, the difference is not a refinement, it is the difference between the design working and not.
The reliability that TCP would have provided is not missed, because DNS handles the same problem itself. If no response arrives, the resolver simply asks again, often a different DNS server. A lost query costs one retry rather than a connection teardown.
That is why UDP 53 carries almost all DNS traffic, and why a packet capture of a normal network shows page after page of single packet DNS exchanges on that port. Running dig against a resolver produces exactly one of them.
The TCP fallbackWhen DNS switches to TCP
The original specification put a hard limit on a DNS response carried over UDP: 512 bytes. Anything larger could not be sent, so the DNS protocol needed a way out.
The mechanism is a single bit. When a DNS server has a response that will not fit, it sends back a reply with the truncated flag set and very little else.
The client sees that flag, opens a TCP connection to port 53 on the same DNS server, and asks the same query again. The response comes back over TCP, where size is not a constraint.
Four things routinely produce answers large enough to trigger it.
DNSSEC. Signatures are large and they travel with the records they sign. A signed DNS response is frequently several times the size of an unsigned one, and this is the single biggest reason large responses became normal.
Records with many values. A domain name with a dozen addresses behind it, or a TXT record holding a long policy, adds up quickly.
IPv6 addresses. An AAAA record is four times the size of an A record, and DNS responses often carry both.
Zone transfers. A secondary DNS server pulling an entire zone from an authoritative primary is not a query at all, it is a bulk copy, and it uses TCP by definition rather than by fallback.
EDNS0 changed the arithmetic without removing the need for TCP. It lets a client advertise that it can accept UDP DNS responses larger than 512 bytes, commonly up to 1232, which avoids the fallback for many responses that would otherwise have needed it. Above whatever the client advertised, the truncation and the TCP retry happen exactly as before.
| Situation | Transport | Why |
|---|---|---|
| Ordinary A or AAAA query | UDP 53 | The response fits in one packet |
| Signed DNSSEC response | UDP, then TCP if large | Signatures push it past the limit |
| Response with many records | UDP, then TCP if large | Size, not record type |
| Zone transfer, AXFR or IXFR | TCP 53 always | A bulk copy needing reliability |
| Response above the EDNS0 size | TCP 53 | Truncated flag, then retry |
Firewall policyWhat to allow on a firewall
The rules are short and the mistakes are consistent.
| Rule | Who | Verdict |
|---|---|---|
| UDP 53 and TCP 53 outbound | Your resolvers only | Allow, both transports |
| UDP 53 and TCP 53 outbound | Every other client | Deny, so filtering applies |
| UDP 53 and TCP 53 inbound | An authoritative server you publish | Allow, if you publish a domain |
| UDP 53 and TCP 53 inbound | A recursive resolver | Deny, an open resolver is an amplifier |
| TCP 53 zone transfer | Named secondary servers | Allow by address, nobody else |
| TCP 853, DNS over TLS | Your resolvers | Allow if you use it |
Allow outbound UDP 53 and TCP 53 to your DNS servers. Both. This is the rule most often written with only UDP in it, and the resulting failure is confusing because most domain names still resolve.
Allow inbound UDP and TCP 53 only on an authoritative DNS server, and only if you are actually publishing a domain to the internet. Almost no business does.
Do not publish a recursive resolver to the internet. An open DNS server is used for amplification attacks: a small forged query produces a large response aimed at a victim, which is a security problem for everybody except the attacker. It is one of the classic ways a network becomes a participant in an attack on somebody else.
Restrict zone transfers to named secondaries. An unrestricted AXFR hands anybody a complete list of every host in the domain, which is free reconnaissance and a standing security exposure.
Block outbound 53 from everything except your DNS servers. This is the rule worth adding rather than the one worth removing. Forcing every client to use the internal resolver means the filtering and the logging actually apply, and a machine that tries to query an outside DNS server is worth knowing about.
That last rule has a specific reason beyond tidiness. DNS is a common exfiltration channel: data is encoded into the domain names being queried, and the queries are answered by an authoritative server the attacker controls.
It looks like ordinary DNS traffic, it passes almost every firewall, and it only becomes visible when the queries have to go through a DNS server that logs them.
DoT and DoHEncrypted DNS moved off port 53
A DNS query on port 53 is plain text in both directions. Anyone on the path reads which domain names a machine is looking up, and can modify the responses, which is the security case for encrypting it.
Two protocols address that, and both moved to different ports.
DNS over TLS uses TCP 853. It is DNS as usual inside a TLS connection, on a port of its own. Because it has its own port, it is easy to permit, easy to block, and easy to see on a firewall.
DNS over HTTPS uses TCP 443. The queries travel as HTTPS requests, indistinguishable from ordinary web traffic on a shared port.
That is the point of it from a privacy standpoint and the problem with it from a network administration standpoint: a browser configured to use it stops using your resolver, and your filtering and logging stop applying, and nothing in the firewall reveals that this happened.
For a business network the practical position is to permit DNS over TLS to the resolvers you chose, and to set the policy that disables DNS over HTTPS in the browsers you manage, so that name resolution keeps going through infrastructure you can see.
PitfallsWhere people go wrong
Allowing UDP 53 and forgetting TCP 53. The most common port 53 mistake. Most DNS queries work, DNSSEC signed domains and a handful of large responses fail, and nobody connects the two.
Assuming DNS is UDP only. It has used both transports since the beginning. The current specifications require support for both.
Leaving a DNS server open to the internet. It will be found and used for amplification within days, and the traffic leaves your network aimed at somebody else.
Allowing zone transfers to anyone. A single AXFR returns every record in the domain. Restrict it to the secondary DNS servers by address.
Letting clients query outside DNS servers. Filtering, logging and split DNS all stop working for any machine that talks to a resolver you do not run.
Ignoring DNS over HTTPS on managed devices. A browser that enables it silently bypasses everything you built on port 53, and the firewall shows only ordinary HTTPS.
Blocking port 53 to stop exfiltration. The clients need DNS. The control is forcing them through a resolver that logs and filters, not removing their ability to resolve names.
ComparisonFour ways to carry a DNS query, and what each one costs you to manage
| Criterion | UDP 53 | TCP 53 | DoT 853 | DoH 443 |
|---|---|---|---|---|
| Carries ordinary lookups | Yes | Rarely | Yes | Yes |
| Carries zone transfers | No | Yes | No | No |
| Size limit | 512, or the EDNS0 size | None in practice | None | None |
| Encrypted | No | No | Yes | Yes |
| Visible as DNS on a firewall | Yes | Yes | Yes | No |
| Must be allowed outbound to resolvers | Yes | Yes | If used | If used |
| Easy to filter and log centrally | Yes | Yes | Yes | No |
The last two rows are the whole administration question. Everything on port 53 is visible and controllable and readable by anyone on the path. DNS over HTTPS reverses both halves of that at once.
FAQFrequently asked questions
What port does DNS use?
Port 53, over both UDP and TCP. UDP carries almost every ordinary lookup and TCP carries anything too large plus every zone transfer.
Is DNS TCP or UDP?
Both. The question assumes a choice that the protocol never made: it uses UDP by default and TCP when the answer will not fit or when the operation is a zone transfer.
When does DNS use TCP?
When a UDP answer would exceed the size the client can accept, which the server signals with a truncated flag, and always for zone transfers between servers.
What is the 512 byte limit?
The original maximum size of a DNS answer over UDP. EDNS0 lets a client advertise a larger size, commonly 1232 bytes, and anything above that still falls back to TCP.
Why is TCP 53 more important than it used to be?
DNSSEC signatures and IPv6 records made large answers ordinary, so the fallback that used to be rare now happens routinely.
What happens if I block TCP 53?
Most lookups still work and specific ones fail, usually signed names and names with many records. It is a confusing failure precisely because DNS mostly works.
What is a zone transfer?
A secondary DNS server copying a whole zone from the primary, using AXFR for the full zone or IXFR for changes. It always uses TCP and should be restricted to named servers.
What is an open resolver and why is it a problem?
A recursive resolver that answers queries from anyone on the internet. Attackers use it for amplification: a small forged query produces a large answer directed at a victim.
Should I block outbound port 53?
Block it from everything except your own resolvers. Clients still resolve names, through infrastructure that filters and logs, and an attempt to reach an outside server becomes visible.
What is DNS over TLS?
DNS inside a TLS connection on TCP port 853. It encrypts the queries and keeps them identifiable as DNS on the network, which makes it the manageable option.
What is DNS over HTTPS and why do administrators dislike it?
DNS queries carried as HTTPS on port 443. It is indistinguishable from web traffic, so a browser using it bypasses the resolver, the filtering and the logging with nothing visible on the firewall.
Does encrypted DNS stop DNS exfiltration?
No, and it can help the attacker. The channel works the same way, and if the queries leave over HTTPS they are harder to see than they were on port 53.
Why does a name fail to resolve while everything else works?
Frequently a large answer, so the query needs the TCP fallback that the firewall is not allowing. Working through the layers will find it, and TCP 53 is worth checking early.
Keep readingRelated concepts
Read next · Protocols TCP vs UDP DNS is the clearest example of a protocol that genuinely needs both, and switches between them mid conversation. Open this next10 min- Ports · 12 min What Is a Port Number? Port 53 is a well known port, and that range has rules about who may bind to it.
- DNS · 14 min DNS Not Resolving A name that fails while everything else works is often a large answer meeting a firewall that only permits UDP.
- DNS · 10 min The SOA Record, Field by Field What has to be reachable before any of this matters.