large organization nameservers sending icmp packets to dns servers.
dotis at mail-abuse.org
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
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
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