DNS Port 53: How to Test UDP and TCP Separately
DNS Port 53: How to Test UDP and TCP Separately
DNS uses port 53 with both UDP and TCP. If you are troubleshooting resolution, send a DNS query over each transport from the network where the problem occurs. Use the same resolver, name and record type for the comparison.
A successful UDP answer tells you that one transaction worked on that path. It leaves open whether TCP can connect and return a DNS response. This matters when a response is truncated, when a client chooses TCP directly, or when a server has to handle full zone transfers. For a useful test, capture the DNS result alongside the transport result. A port check and a successful name lookup answer different questions.
Test both transports to the same DNS server. The paths show transport options, not a measured network result.
Identify the DNS server and network path
Start by finding the resolver the affected client is expected to use. A workstation, a container and an application running inside that container may send requests through different intermediaries. A diagnostic query pointed at an external resolver may be useful as a separate comparison, but it does not test the enterprise resolver path. Record the source subnet or workload, the destination server address and whether the incident began after a routing, firewall or resolver change. These details make the result reproducible by someone who was not present when the test was run.
Distinguish a recursive resolver from an authoritative name server before choosing the test name. For a recursive resolver, choose a name that clients in the affected network should be able to resolve. For an authoritative server, choose a name and type within a zone the server is meant to serve, and disable recursion for that direct probe. A recursive test can succeed from cache even while the resolver has trouble reaching an upstream server. An authoritative test answers a narrower question about the server and zone you address directly.
If several resolver addresses are distributed to clients, capture which one is being tested. A user report that resolution works intermittently may reflect a difference between resolver endpoints or between source networks. Testing the first address alone can miss that pattern. Start with one failing client and one known working comparison point. Keep each result associated with its source and destination so the network and DNS teams can reproduce the relevant path.
Run a paired UDP and TCP query
The examples below use a documentation address and domain. Substitute your approved resolver address and a test name that you expect to resolve in that environment. With dig, a UDP probe that does not automatically retry a truncated reply over TCP can be written as:dig @192.0.2.53 service.example. A +notcp +ignore +tries=1 +time=3
Run the matching TCP probe with the same name and record type:dig @192.0.2.53 service.example. A +tcp +tries=1 +time=3
The paired results are more informative than two unrelated lookup commands. For both queries, save the reported server, elapsed time, response code and the relevant flags and answer records. Note whether the result was a full answer, a truncated response, a DNS error or a timeout. A response such as REFUSED shows that a DNS message came back, even though the server did not perform the requested operation. The presence of a reply is useful transport evidence and still requires a separate check against your expected DNS behavior.
The short timeout and single attempt make these examples useful for a controlled comparison. They do not establish an appropriate production timeout or retry policy. If a test fails once, record it and repeat under the same conditions before treating it as a stable result. If several runs alternate between success and failure, preserve the individual observations. An average response time by itself can hide failed transactions, and a pasted answer with no timestamp can be difficult to correlate with firewall or resolver logs.
Tell truncation apart from packet loss
Conceptual exchanges: a received TC flag differs from a timeout. These are protocol diagrams, not captured dig output.
The TC flag indicates that a DNS response was truncated. In a UDP probe that preserves the original reply, seeing this flag tells you that a DNS response came back but that its contents were incomplete. Run the TCP query to find out whether the full exchange works over the other transport. The IETF discusses transport selection and TCP support in RFC 7766. In practical testing, the important point is to record the first UDP result and the TCP result separately, even when a diagnostic tool can handle the retry automatically.
A UDP timeout has different evidence. You received no usable response before the test deadline. That observation alone cannot tell you whether the request reached the server, whether the server declined or failed to reply, or whether the reply was lost. A short answer may return successfully while a larger answer times out. Compare a small known-good record with an approved test record that produces a larger response, and check the resolver and network logs before concluding that the same rule affects both.
A useful incident note states what happened in order. For example, a small A query returned a complete UDP answer, a separate query returned a truncated UDP response, and the TCP retry to the same destination timed out. Those details give another engineer a starting point. The first two observations establish that some UDP exchanges worked. The last observation identifies a TCP exchange that needs investigation. They do not by themselves identify the firewall rule or prove a server fault.
Read each failure at the layer that produced it
If UDP works and TCP fails, first establish whether the TCP connection was refused, timed out or connected without returning a usable DNS message. A connection refusal can point toward a listener or an active rejection, while a timeout calls for checking the path and any devices that filter or route the traffic. Compare the observed behavior with server logs and, where authorized, packet captures. An open TCP socket does not establish that the server returned the expected DNS answer.
If TCP works and UDP fails, use the same source and destination addresses for the next check. Confirm that the service is expected to answer UDP on that address, then check the UDP-specific policy in each direction. A rule allowing TCP on destination port 53 does not also allow UDP. On a stateful firewall, review how the expected response is tracked. On a path with stateless filtering, confirm the allowed return traffic using the actual packet directions. Make the policy change only after you know which segment drops the exchange.
If both transports return the same unexpected DNS response, follow the DNS evidence. An unexpected NXDOMAIN, an empty answer or an unexpected address can involve the query name, zone data, recursion policy, cache or differences between internal and public views. Compare the answer against the expected record and the client's configured resolver. The shared result may be more useful than repeatedly testing connectivity. Conversely, when neither transport replies, check shared prerequisites such as the destination address, interface, route and applicable access policy before assuming two independent transport faults.
Keep transfer checks separate from client lookups
An ordinary lookup and a full zone transfer are different operations. Full transfers using AXFR use TCP, but a successful TCP lookup does not show that a server allows a particular secondary server to transfer a zone. If transfers are part of the deployment, verify the configured primary and secondary endpoints, the zone name, the permitted identities and the expected zone revision. Run the transfer check only from the approved secondary or an authorized test host. A refusal from an arbitrary client may be the intended access control behavior.
That distinction also works in the other direction. A successful authorized transfer establishes something about the primary-to-secondary path. It does not test queries from the application subnet to the recursive resolver. Keep a separate record for client resolution, upstream forwarding and zone transfer where those paths exist. Each has a different source, destination and expected result. Combining them under a single status such as “port 53 open” makes it difficult to tell which operation was actually tested.
Make the evidence usable during a change
Illustrative record, not dig output or live test evidence. A UDP reply with TC=1 is incomplete and calls for a TCP retry. Record the full flags, message size, answer and time from the actual tests; documentation addresses are used.
Before a firewall or resolver change, choose a short list of probes and write down the expected result for each. Include a normal lookup on each transport, the source locations that matter and a representative query for any special behavior you need to preserve. Save a baseline from the actual application network. After the change, repeat the same probes and compare the response code, relevant flags and answer content. Timing is meaningful when the test conditions are comparable and when failures are included in the record.
For example, consider a branch office that can resolve a simple record but reports failures on a different application name. Begin with the branch resolver and the affected application name. Capture the UDP and TCP results, then repeat from an approved comparison location. If the branch shows UDP truncation followed by TCP failure while the comparison location gets a full TCP response from the same resolver, investigate what differs on those network paths. If both locations get an unexpected DNS answer, check the name, record type and resolver configuration before asking for a broader firewall exception.
The final handoff should let someone else rerun the test without guessing. Record the client location, resolver address, query name, query type, transport, expected answer and observed result. For a failure, add the timestamp and the next owner who can inspect that segment. When evaluating an enterprise deployment, use the ZDNS DNS product information to identify what to discuss with the vendor, then confirm the exact product version and configuration against your test plan. A paired query is a practical starting point for acceptance because it shows how both transport paths actually behave for the clients that depend on them.