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