40

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

Community
  • 1
StanTastic
  • 810
  • 1
  • 7
  • 24
  • 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
  • BTW. Saying `3.` would be stupid because of NAT is not actually a valid argument because NAT did not exist when DNS was designed. If DNS had been done like your option `3.`, then it would have been stupid to make a NAT which could not handle that. But you could argue that `3.` is problematic because it would require every DNS client to bind to a TCP port before sending any requests and somehow communicate to the DNS server where it is listening. – kasperd Jun 11 '15 at 20:52

1 Answers1

51

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://www.rfc-editor.org/rfc/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.

Community
  • 1
faker
  • 17,326
  • 2
  • 60
  • 69