large organization nameservers sending icmp packets to dns servers.

Paul Vixie paul at
Thu Aug 9 21:05:26 UTC 2007

> > the resources given a nameserver to TCP connections are tightly
> > controlled, as described in RFC 1035 4.2.2.  so while TCP/53 can become
> > unreliable during high load, the problems will be felt by initiators not
> > targets.
> The relevant entry in Section 1035 4.2.2 recommends that the server not
> block other activities waiting for TCP data.  This is not exactly a
> requirement that TCP should fail before UDP.

it is semantically equivilent to such a requirement, in that UDP/53 is an
"other activity" performed by name servers.  it happens to be implemented
this way in all versions of BIND starting in 4.8 or so (when named-xfer was
made a separate executable), all versions of Windows DNS, and all current
name server implementations i am aware of (including powerdns, nominum ANS,
and NSD).  so while "not exactly", it's "effectively" a requirement, and i
think we ought to design our systems with this constraint as a given.

> The concern leading to a suggestion that TCP always fail was a bit
> different.  A growing practice treats DNS as a type of web server when used
> to publish rather bulky script-like resource records.  Due to typical sizes,
> it is rather common to find these records depend upon TCP fallback.  This
> problem occurred with paypal, for example.  TCP fallback is especially
> problematic when these records are given wildcards.  Such fallback increases
> the amplification associated with an exploit related to the use of the
> script within the record.
> Of course there are better ways to solve this problem, but few are as
> certain.

i think you're advising folks to monitor their authority servers to find out
how many truncated responses are going out and how many TCP sessions result
from these truncations and how many of these TCP sessions are killed by the
RFC1035 4.2.2 connection management logic, and if the numbers seem high, then
they ought to change their applications and DNS content so that truncations
no longer result.

or perhaps you're asking that EDNS be more widely implemented, that it not
be blocked by firewalls or perverted by hotelroom DNS middleboxes, and that
firewalls start allowing UDP fragments (which don't have port numbers and
therefore won't be allowed by UDP/53 rules).

i would agree with either recommendation.

but i won't agree that TCP creates stability or load problems for servers.

More information about the NANOG mailing list