When a DNS lookup times out, the problem may not be the domain name. Traditional DNS uses port 53 over both UDP and TCP, and allowing only one transport can break some queries or DNS operations. Encrypted DNS uses different transports and commonly different ports.
Knowing which endpoint and transport your client actually uses makes firewall rules and troubleshooting much less guesswork.
The short version
| DNS method | Common port and transport | Typical role |
|---|---|---|
| Traditional DNS | UDP/53 and TCP/53 | Queries to a resolver; TCP is also used for larger responses and zone transfers |
| DNS over TLS (DoT) | Usually TCP/853 | DNS queries carried in a TLS connection |
| DNS over HTTPS (DoH) | Usually HTTPS/443 | DNS messages carried over HTTPS |
These are conventions, not guarantees. A client or network can be configured to use a specific endpoint or a custom port. If you need to allow a particular encrypted DNS service, check its configuration rather than assuming that opening port 53 is enough.
Why DNS uses both UDP and TCP
Many ordinary DNS lookups use UDP. It suits short request-and-response exchanges without setting up a connection. But TCP is a normal part of DNS too—not just an obsolete fallback.
A response that cannot fit the available UDP exchange may be marked as truncated, prompting the client to retry over TCP. DNS can also use TCP directly, including for zone transfers between authoritative servers. A firewall that permits UDP/53 but blocks TCP/53 can therefore cause failures that seem inconsistent: some lookups work, while others do not.
Port 53 usually means the destination port on the DNS server. The client sends from a temporary high-numbered source port, and the reply comes back to that port:
Client: 192.0.2.25:53041 → Resolver: 203.0.113.53:53 UDP
Reply: Resolver: 203.0.113.53:53 → Client: 192.0.2.25:53041 UDP
The example source port is illustrative; the operating system chooses a temporary port. With a stateful firewall, allowing an outbound query generally allows its matching reply. A stateless policy may also need explicit rules for return traffic.
Choose firewall rules based on the machine’s role
A DNS client, a private recursive resolver, and a public authoritative server do not need identical rules.
- Client: allow outbound UDP and TCP to the configured resolver on destination port 53, with replies permitted.
- Private recursive resolver: allow inbound UDP and TCP/53 from the client networks that should use it. Restrict access to those networks.
- Authoritative server: allow inbound UDP and TCP/53 from intended clients and secondary servers. Control zone transfers separately.
- Encrypted DNS client: allow the configured endpoint and transport; DoT commonly uses TCP/853, while DoH commonly uses HTTPS on port 443.
Do not expose inbound DNS to the internet unless the server is intentionally providing a public DNS service. An unrestricted public recursive resolver can be abused for reflection attacks.
On Ubuntu, UFW rules for both traditional DNS transports look like this:
sudo ufw allow 53/udp
sudo ufw allow 53/tcp
sudo ufw status
Apply inbound rules only when the server should accept queries from the relevant networks. A host firewall is just one layer: a cloud firewall, router, or network ACL can still block traffic. If you need a refresher on the rule syntax and verification, see this guide to allowing ports with UFW.
Test DNS, not just a port
A port check does not tell you whether a DNS server returned the record you expected. Use a DNS-aware tool such as dig to test a query against a resolver:
dig example.com @1.1.1.1
dig +tcp example.com @1.1.1.1
The first command uses normal DNS transport selection, typically UDP when the answer fits. The second explicitly requests TCP. If one works and the other times out, investigate the corresponding transport and network path. Use an approved resolver if your network requires one.
On a Linux DNS server, check for local listeners on port 53 with:
sudo ss -lntup | grep ':53'
A listener confirms that a process has bound a local socket; it does not prove remote clients can reach it. Check the service’s bind address as well as the host, cloud, and upstream firewall rules. For more ways to distinguish local listeners from reachable ports, see how to check open ports on Linux.
DNS records do not set a website’s port
An A record maps a name to an IPv4 address; an AAAA record maps it to an IPv6 address. A CNAME aliases one name to another. These records do not tell a browser to connect to an application on port 8080.
For a nonstandard web port, the client generally needs the port in the URL, such as https://example.com:8443/, or a reverse proxy can accept traffic on a normal web port and forward it to the application. DNS resolution itself does not do that forwarding.
DNS also has SRV records that can publish a service’s hostname and port for clients that support SRV lookups. They are a service-discovery mechanism, not a universal redirect: browsers do not generally use SRV records to choose a port for an ordinary website.
A practical troubleshooting order
When a lookup fails, work through the request rather than opening ports at random:
- Confirm which resolver the client is querying.
- Identify whether the client uses traditional DNS, DoT, or DoH.
- For traditional DNS, check both UDP and TCP port 53 where required.
- Confirm the server is running and listening on the intended interface.
- Check every firewall layer and whether return traffic is permitted.
- Use a DNS query tool to verify the answer, not only a generic TCP connectivity test.
The key distinction is simple: port numbers depend on the DNS transport, and firewall rules depend on the machine’s role. Verify both before changing network policy.
I originally published a more detailed version of this guide on the SSHFlow blog.
I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.
Top comments (0)