Before anyone asks: I've seen When do DNS queries use TCP instead of UDP? and it doesn't answer my question.

All I keep hearing is "if the answer is too long, DNS will use TCP". This does not explain how it happens though.

So here's the situation: DNS client asks for resolution of a record using UDP. The record is too long for UDP:

  1. server answers with specific opcode, to have client switch to TCP
  2. server doesn't answer at all, and client re-tries over TCP
  3. server opens TCP connection to client (stupid, if you count NAT, but who knows?)
  4. client somehow (?) 'knows' that given query should be run over TCP so it doesn't bother with UDP in the first place
  5. DNS pixies magically turn UDP into TCP when needed

I've been looking all over the internet for the answer, but there's lot of noise (see above), and I can't seem to write proper Google query for that (nor can I find the info in RFCs, for that matter).

  • 2
    All I could find was in RFC5966: "A resolver SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason to expect the response would be truncated if it were sent over UDP (with or without EDNS0) or for other operational reasons, in particular, if it already has an open TCP connection to the server.". When should resolver "expect" that the response will be truncated? – StanTastic Jun 11 '15 at 10:53
  • 7
    An obvious example would be if a previous request for the same record was too long to fit in a UDP datagram. – David Schwartz Jun 11 '15 at 10:55
  • 1
    So there's an opcode that says 'truncated', right? And it switches then - basically what I thought, it's the most obvious solution. – StanTastic Jun 11 '15 at 11:12
  • 1
    Case (d) may be a wise choice if the query contains multiple "questions" (addresses to resolve). If you need to resolve 100 addresses, you're not going to be able to fit the response in a single UDP packet. – MSalters Jun 11 '15 at 14:16
  • 1
    1. and 4. are both roughly correct (which of the two depends on circumstances). – kasperd Jun 11 '15 at 20:46

The client does not know in advance that the response will be too large, so it will query the server via UDP.
The server will respond via UDP and will include as much as possible and set the truncated header bit ("TC" http://www.networksorcery.com/enp/protocol/dns.htm).
The client can then resend the request via TCP and get the full response.

See also: https://tools.ietf.org/html/rfc5966

In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below), the normal behaviour of any DNS server needing to send a UDP response that would exceed the 512-byte limit is for the server to truncate the response so that it fits within that limit and then set the TC flag in the response header. When the client receives such a response, it takes the TC flag as an indication that it should retry over TCP instead.

And: https://www.ietf.org/rfc/rfc2181.txt

And as mentioned in the comments, of course DNS zone transfers are always using TCP.

  • 2
    RFC 5966 also notes that TCP is always used for zone transfers. – Matt Nordhoff Jun 11 '15 at 12:39
  • @MattNordhoff Right, that's true and good to mention. This was more aimed at the 'how does the switch from UDP to TCP work?' angle. But I'll add it to the answer. – faker Jun 11 '15 at 12:43
  • However if there is already a TCP connection it will only use TCP – Jim B Jun 11 '15 at 13:37
  • Oh, that's interesting. So when does it fall back to UDP? – StanTastic Jun 13 '15 at 10:43
  • @JimB Are you sure about that? I don't think it keeps a persistent TCP connection open. – Barmar Jun 16 '15 at 21:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.