|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: large organization nameservers sending icmp packets to dns servers.
> > 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.
|