35

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.

Caderade
  • 353
  • 1
  • 3
  • 5

4 Answers4

40

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

George Erhard
  • 804
  • 6
  • 12
  • 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 Mar 23 '17 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. – AbraCadaver Mar 23 '17 at 20:03
  • That's what I was originally thinking @AbraCadaver but based on the other folks feedback, it sounds like that's not necessarily the case - looks like DNS queries can begin as TCP. If I'm interpreting everything correctly. I think the take away is, if I want full coverage of all DNS queries, I have to capture both UDP and TCP DNS traffic destined for our DNS servers and Domain Controllers. Sniffing just UDP could leave a gap. – Caderade Mar 23 '17 at 20:40
  • 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. – AbraCadaver Mar 23 '17 at 21:08
  • 1
    Can clients use TCP for small responses anyway? – user541686 Mar 25 '17 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 Mar 26 '17 at 15:36
  • @AbraCadaver Interesting, so technically, I should have coverage for DNS queries if I'm only looking at UDP. I wouldn't care if responses came back truncated, etc. As long as we can ID which host made which FQDN resolution requests. And Bryan - Good point. In our case, I don't know that we've setup our DNS servers to support EDNS (need to check). I guess the worry could be that a malicious actor could try to force TCP for DNS queries, but they'd need to know we're only looking at UDP to begin with. Anyways, thanks for all the input folks! – Caderade Mar 27 '17 at 14:48
29

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.

Community
  • 1
Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • 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 Mar 24 '17 at 08: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 Mar 24 '17 at 16:54
6

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 6.1.3.2 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.

Community
  • 1
Ron Maupin
  • 3,158
  • 1
  • 11
  • 16
  • 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 Mar 23 '17 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 Mar 23 '17 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 Mar 23 '17 at 19:21
  • 1
    The `INTERNET STANDARD` RFC is https://tools.ietf.org/html/rfc1034. You're quoting a `PROPOSED STANDARD` to require TCP. – AbraCadaver Mar 23 '17 at 20:07
  • 3
    That is a Standards Track RFC that updated a previous Standards Track RFC about the same thing. [This answer](http://serverfault.com/a/755655/324849) here on [sf] 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 Mar 23 '17 at 20:15
3

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.

Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
  • question has nothing to do with filtering, and your answer adds nothing over the other answers – Bryan Mar 26 '17 at 15:38
  • @Bryan thanks for your very helpful and useful comment! – Patrick Mevzek Mar 26 '17 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 Mar 27 '17 at 14:55