I've spent a bit of time researching this topic and can't seem to find an exact answer, so I'm fairly confident it's not a duplicate, and while my question is based on a security need, I think it's still safe to ask here but let me know if I need to move it the security community.

Essentially, do DNS queries ever use TCP (if so, what scenario could this occur)? Again, I'm only talking about queries. Is it possible for them to travel over TCP? If domains can only be a max of 253 bytes in length, and UDP packets can be as large as 512 bytes, won't queries always go out as UDP? I didn't think a resolvable query could be large enough to require the use of TCP. If a DNS server ever got a request for a domain larger than 253 bytes, would the server drop it/not try and resolve it? I'm certain I've made some false assumptions here.

For some context, I'm working with the security group to onboard DNS queries into their security monitoring tool, and for various reasons we've decided we will capture this traffic via standard packet capture on DNS servers and domain controllers. The core requirement is to capture all DNS queries so they can identify what client attempted to resolve any given domain. Based on this requirement, we aren't concerned with capturing DNS responses or other traffic like zone transfers, which is also driven by the fact that we need to limit log volume as much as possible. As such, we are planning to capture only DNS queries destined for the DNS server and sent over UDP. For more context (kind of question scope creeping here), it's now been brought up that we might need to expand security's visibility so they can monitor for activity like covert channels running over DNS (which would present the need to capture DNS responses as well, and subsequently TCP traffic). But even in that sort of scenario, I thought any outbound DNS traffic would be in the form of lookups/queries, and that these would always be over UDP, even if from a malicious source (because of my reasoning in the first paragraph). So this brings up some additional questions:

  • Wouldn we at minimum be capturing half of the conversation with the approach I outlined? Or would a client ever send out DNS traffic that isn't in the form of a query? (maybe like some kind of reply to a DNS server's response, and maybe ends up going out over TCP)

  • Can DNS queries be modified to use TCP? Would a DNS server accept and respond to a DNS query coming over TCP?

Not sure if it's relevant, but we do limit DNS requests to authorized DNS servers and block all other traffic outbound over port 53. I'm definitely a rookie, so I'm sorry if my question isn't compliant, and let me know how I should modify.

  • 2
    Paging @Alnitak, we're discussing your baby. :)
    – Andrew B
    Commented Mar 23, 2017 at 23:48
  • How can I force default DNS query to work in TCP mode?. Though an OS X/macOS q/a with some mods it also works for Linux/Windows.
    – klanomath
    Commented Mar 26, 2017 at 13:52
  • Of course nowadays with DNS over HTTPS and DNS over TLS and soon DNS over QUIC... Commented Apr 5, 2019 at 21:04
  • Why not redirect all DNS queries to (a) DNS server(s) of your choice? Commented May 20, 2019 at 6:04

4 Answers 4


Normal DNS queries use UDP port 53, but longer queries (> 512 octets) will receive a 'truncated' reply, that results in a TCP 53 conversation to facilitate sending/receiving the entire query. Also, the DNS server binds to port 53, but the query itself originates on a random high-numbered port (49152 or above) sent to port 53. The response will be returned to this same port from port 53.

Network Ports Used by DNS | Microsoft Docs

So, if you're planning on doing some security snooping on DNS queries from your network, you'll need to take the above into account.

As for non-lookup traffic, consider that DNS also uses zone transfers (query type AXFR) to update other DNS servers with new records. A man in the middle attack can begin with such a transfer, DDOS'ing a Primary name server so that it's too busy to respond to a Secondary asking for updated records. The hacker then spoofs that same Primary to feed 'poisoned' records to the Secondary, that redirect popular DNS domains to compromised hosts.

So your security audit should pay close attention to query type AXFR, and your DNS systems should only accept AXFR exchanges from specific IP addresses.

SANS Institute InfoSec Reading Room | sans.org

  • 1
    Thanks George, really helpful stuff! So to quickly clarify on your first sentence - a UDP packet can only fit 512 bytes, right? So if a DNS query was larger than 512, wouldn't it start out over TCP right out of the gate? I tried testing this myself by running wireshark and using nslookup to resolve large domains, but it seems to block me from trying domains larger than 200 characters (not the exact number, but the point is I couldn't fully test this scenario it out).
    – Caderade
    Commented Mar 23, 2017 at 19:03
  • 3
    It's not the "query" but the "response" that would be more than 512Bytes and the client wouldn't know what the "response" would be. Commented Mar 23, 2017 at 20:03
  • 7
    @Caderade Yes, you are correct that they can be TCP or UDP, however only Zone Transfers will begin as TCP. Client queries will be UDP unless they get a response from the server that has the truncate bit set. Then can then use TCP. Commented Mar 23, 2017 at 21:08
  • 1
    Can clients use TCP for small responses anyway?
    – user541686
    Commented Mar 25, 2017 at 19:46
  • 2
    "a UDP packet can only fit 512 bytes" No, it's the assumption that the client's buffer can only fit 512 bytes that causes servers to behave this way. Servers can be notified of a longer buffer using EDNS.
    – Bryan
    Commented Mar 26, 2017 at 15:36

This started as a comment to George's answer, but it got long. The larger picture is somewhat complicated, as it requires understanding some history.

  • RFC 1035 originally called for a limit of 512 bytes in order to avoid UDP fragmentation. Fragmented UDP datagrams and TCP were chosen as the options of last resort in order to minimize the overhead of DNS transactions. Zone transfers always use TCP, due to zone transfers taking up >512 bytes by their very nature. (it would be a waste of bandwidth to begin with UDP at all)

  • TCP retry on truncation is widely supported as it has been specified in RFC 1123 since 1989.

  • EDNS(0) is defined by RFC 6891 (2013), and before that existed as a Proposed Standard dating back to 1999. It defines a mechanism where clients and servers can negotiate UDP sizes greater than 512. Due to the newness of EDNS(0), many hardware appliances make assumptions about the structure of DNS packets that cause compliant packets to be discarded. The most frequent reason is an assumption that DNS messages of over 512 bytes are invalid, but this is one among several.

If we break that out into the observed behaviors:

  1. DNS queries usually start as UDP, unless it's known ahead of time that the reply will be too large to begin with. (zone transfers)
  2. The reply may trigger a TCP retry in the client if a truncated reply is seen. This is fairly well supported.
  3. A UDP reply of greater than 512 bytes may be seen if the client used EDNS(0) to advertise a larger payload, and the receiving server supports it. This will only happen if hardware sitting between the two does not interfere and result in a dropped or mangled packet.
  4. The client may elect to retry an EDNS(0) query with a smaller advertised payload if a reply is not seen, but specifics will vary between implementations.
  • It's important to note that the reply which finally makes it through may be too large to fit within the requested size, which results in behavior #2 above. (ye olde TCP retry)
  • The client side may choose to remember the size that finally resulted in a success. This allows it to avoid wasting unnecessary queries probing it out again. To do otherwise would be quite wasteful, particularly if the final result required TCP fallback.

You should also keep in mind that RFC 7766 allows for connection reuse over TCP, and it's possible to encounter query pipelining over TCP in the wild. Some tools do not detect DNS queries beyond the first seen in a TCP session, dnscap being an example of such.

  • One of the reasons to get truncate bit set is Response Rate Limiting (RRL). As a DNS amplification mitigation technique the server might send truncated packets to make well-behaving clients switch to TCP, hopefully preventing replies to packets from fake addresses.
    – Edheldil
    Commented Mar 24, 2017 at 8:02
  • Connection reuse: so teach your resolver to first ask for google.com, before it asks for scantycladladies.com, then dnscap does not notice. ;-)
    – Lenne
    Commented Mar 24, 2017 at 16:54

There is RFC 7766, DNS Transport over TCP - Implementation Requirements.

  1. Introduction

Most DNS [RFC1034] transactions take place over UDP [RFC768]. TCP [RFC793] is always used for full zone transfers (using AXFR) and is often used for messages whose sizes exceed the DNS protocol's original 512-byte limit. The growing deployment of DNS Security (DNSSEC) and IPv6 has increased response sizes and therefore the use of TCP. The need for increased TCP use has also been driven by the protection it provides against address spoofing and therefore exploitation of DNS in reflection/amplification attacks. It is now widely used in Response Rate Limiting [RRL1] [RRL2]. Additionally, recent work on DNS privacy solutions such as [DNS-over-TLS] is another motivation to revisit DNS-over-TCP requirements.

Section of [RFC1123] states:

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

However, some implementors have taken the text quoted above to mean that TCP support is an optional feature of the DNS protocol.

The majority of DNS server operators already support TCP, and the default configuration for most software implementations is to support TCP. The primary audience for this document is those implementors whose limited support for TCP restricts interoperability and hinders deployment of new DNS features.

This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation.

There are several advantages and disadvantages to the increased use of TCP (see Appendix A) as well as implementation details that need to be considered. This document addresses these issues and presents TCP as a valid transport alternative for DNS. It extends the content of [RFC5966], with additional considerations and lessons learned from research, developments, and implementation of TCP in DNS and in other Internet protocols.

Whilst this document makes no specific requirements for operators of DNS servers to meet, it does offer some suggestions to operators to help ensure that support for TCP on their servers and network is optimal. It should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) will probably result in resolution failure and/or application-level timeouts.

  • 2
    Hey Ron - I did actually read that RFC prior to posting, but for instance, if you look in the first paragraph, it appears to emphasize that TCP is required to support larger responses - "The growing deployment of DNS Security (DNSSEC) and IPv6 has increased response sizes and therefore the use of TCP". Again, my question was about queries, but thanks anyways.
    – Caderade
    Commented Mar 23, 2017 at 18:54
  • 4
    The RFC makes it absolutely clear that TCP is required to be supported for DNS, and it does discuss the use of TCP by clients. For example, "Clients utilizing TCP for DNS need to always be prepared to re-establish connections or otherwise retry outstanding queries."
    – Ron Maupin
    Commented Mar 23, 2017 at 19:09
  • Good point. I'd say that comment was actually helpful given the added clarity. My point is, I actually did read the RFC and it still wasn't super clear to me that queries could start out using TCP, so when you just dump the RFC for an answer, while comical, it wasn't really helpful. It read to me like, queries go over UDP and if the response is too large, the DNS server would let the client know it needs to start this all over and perform it over TCP. So I thought I'd still meet my original requirement because I would have captured the original request. Regardless, I do appreciate your input.
    – Caderade
    Commented Mar 23, 2017 at 19:21
  • 1
    The INTERNET STANDARD RFC is tools.ietf.org/html/rfc1034. You're quoting a PROPOSED STANDARD to require TCP. Commented Mar 23, 2017 at 20:07
  • 3
    That is a Standards Track RFC that updated a previous Standards Track RFC about the same thing. This answer here on Server Fault explains such things. Even in the document you reference, it says, "In the Internet, queries are carried in UDP datagrams or over TCP connections." RFC 7766 is to clarify that TCP is a required, rather than optional, part of DNS.
    – Ron Maupin
    Commented Mar 23, 2017 at 20:15

You should not filter TCP/53 in any direction. For example, nsupdate queries may use TCP as soon as the request is too big (which can happen fast). So you should let UDP and TCP for port 53 (in IPv4 & V6 !) flow in all directions.

Also there is more and more work towards DNS over TLS, so TCP will be needed in both directions. See RFC7858.

  • question has nothing to do with filtering, and your answer adds nothing over the other answers
    – Bryan
    Commented Mar 26, 2017 at 15:38
  • @Bryan thanks for your very helpful and useful comment! Commented Mar 26, 2017 at 16:32
  • @PatrickMevzek Understood - what I was trying to say is we only allow traffic to specific IP addresses beyond our perimeter over port 53 (TCP and UDP are allowed though).
    – Caderade
    Commented Mar 27, 2017 at 14:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .