Subject: Use same server after truncated response?

From: Peter Koch <[email-masked]>
Date: Mon, 04 Apr 2005 14:18:36 +0200

Our nameserver was hit by a noticeable number of TCP queries due to an
IN-ADDR.ARPA zone containing an entry with lots of PTR RRs. However,
the truncated responses were not sent by our server (the delegation happened
to be lame), so why did we see the TCP queries at all (the other delegees
were authoritatively responsive over both UDP and TCP)?

RFC 2181 says:

   Where TC is set, the partial RRSet that would not completely fit may
   be left in the response.  When a DNS client receives a reply with TC
   set, it should ignore that response, and query again, using a
   mechanism, such as a TCP connection, that will permit larger replies.

All misconfigurations involved in this particular case set aside, would
it be safe to assume that a resolver should "retry" via TCP only the
server that provided the TC response?

-Peter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Florian Weimer <[email-masked]>
Date: Mon, 04 Apr 2005 15:13:57 +0200

> server that provided the TC response?

No, because only a subset of the authoritative servers might provide
TCP service.  This is not an uncommon (mis)configuration, AFAIK.

It's also wrong to assume that TCP fallback only occurs due to
truncated responses.  A resolver might detect that is subject to a
blind spoofing (or even a DoS) attack, and fallback to TCP to thwart
it.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 04 Apr 2005 22:24:54 +0900

> server that provided the TC response?

Interesting phenomena.

Given that TC is set only if there is insufficient room to answer
a required query, it is reasonable to use TCP for any other server.

However, as a client considers the server originally returned TC
best, there is no good reason to retry the server other than
the original.

So far, your assumption seems to be safe.

Then, because of overloading, rate limiting on TCP query or something
else on the original, the TCP retry can fail.

Now, other servers should be tried.

However, there is no reason to try UDP even though it is assured
to be retried by TCP.

							Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Mon, 04 Apr 2005 15:51:50 +0000

> blind spoofing (or even a DoS) attack, and fallback to TCP to thwart

in particular, i've been on hotel wireless nets that captured, rewrote,
and otherwise spoofed udp/53, but which were fully transparent to tcp/53,
and i've occasionally therefore configured my resolver to "always use tcp".

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Apr 2005 23:58:56 -0000

> server that provided the TC response?

No. Stop and think about your assumption for a moment: what happens if
the TCP query fails? Failing to try another server would be a serious
reliability mistake. Trying another server by UDP first would be silly.

Florian Weimer writes:
> truncated responses.

No, it isn't wrong. RFC 1123, section 6.1.2.3, specifically requires all
clients and caches to start with UDP. TCP is allowed if a UDP response
says TC, and TCP is allowed by ``private agreement,'' but starting with
TCP to an unknown server is a protocol violation. You lose access to an
increasingly large portion of the DNS tree if you screw this up.

Masataka Ohta writes:
> a client considers the server originally returned TC best

Some clients work that way. Others don't. (The ``best server'' approach
does a poor job of balancing loads, although this particular aspect of
the approach is relatively harmless.)

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Florian Weimer <[email-masked]>
Date: Tue, 05 Apr 2005 02:53:00 +0200

* D. J. Bernstein:

> clients and caches to start with UDP.

The next paragraph (in section 6.1.3.2) implies that servers SHOULD
reply to TCP-only queries nevertheless, so I don't see a problem.
(BIND follows the SHOULD, or SHOULD NOT in the wording of the RFC.)

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Apr 2005 04:19:13 -0000

Florian Weimer writes:
> servers SHOULD reply to TCP-only queries

The spec recommends that servers respond to TCP. Some servers have local
data that requires TCP; other servers don't. Some DNS administrators
turn on TCP; some don't. (Even at BIND sites, TCP can be firewalled.)

Meanwhile, except when there's a ``private agreement'' with the server,
the spec REQUIRES that clients and caches start with UDP. Starting with
TCP means violating the protocol. This protocol violation would produce
frequent interoperability failures if anyone were dumb enough to do it.

> so I don't see a problem

The problem is that you're advocating interoperability failures. New DNS
implementors might not have the experience necessary to realize that
your advice is bogus.

---

From: Peter Koch <[email-masked]>
Date: Thu, 07 Apr 2005 20:39:38 +0200

> reliability mistake. Trying another server by UDP first would be silly.

I agree that totally failing to try another server would be unwise, but
here are two reasons for trying UDP first anyway:

1) The server might be delegated lame and that can be communicated cheaper
   in UDP

2) This particular server might not provide a truncated response, e.g. because
   it responds with a referral since it is not authoritative for that
   zone while the first server (giving TC/UDP) was authoritative for both
   the child and the parent.

Admittedly it's arguable which strategy is more cost effective in the long run.
In the particular case I mentioned it was a firewall at the resolver side that
prevented the TCP queries from being established, so the resolver hit us
with TCP (attempts) although it hat received the truncated packet from
elsewhere.

-Peter