large organization nameservers sending icmp packets to dns servers.

Douglas Otis dotis at
Fri Aug 10 23:11:04 UTC 2007

On Aug 9, 2007, at 2:05 PM, Paul Vixie wrote:

Your comments have helped.

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

Monitoring is a good recommendation, as many incorrectly estimate  
record limits.  Wildcard resources should also be checked against  
maximal labels.  Fallback may occur with resource records  
encompassing a bit more than a couple hundred bytes.  The assurance  
TCP will fail first is heartening.  How this protection interacts  
with an emerging exploit could be interesting.  I'll try to setup  
some tests and be less pragmatic.

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

TCP offers a means to escape UDP related issues.  On the other hand,  
blocking TCP may offer the necessary motivation for having these UDP  
issues fixed.  After all, only UDP should be required.  When TCP is  
designed to readily fail, reliance upon TCP seems questionable.  As  
DNSSEC in introduced, TCP could be relied upon in the growing number  
of instances where UDP is improperly handled.  UDP handling may have  
been easier had EDNS been limited to 1280 bytes.  On the other hand,  
potentially larger messages may offer the necessary motivation for  
adding ACLs on recursive DNS, and deploying BCP 38.

No pain, no gain might be a motto that applies equally to DNS as it  
does for weight lifting.


More information about the NANOG mailing list