Cisco Pix drops UDP packets larger than 512 bytes

[Jean-Christophe Smith]

RFC 1035

---------------------------------------------------
2.3.4. Size limits

Various objects and parameters in the DNS have size limits.  They are
listed below.  Some could be easily changed, others are more
fundamental.

labels          63 octets or less

names           255 octets or less

TTL             positive values of a signed 32 bit number.

UDP messages    512 octets or less

---------------------------------------------------
4.2.1. UDP usage

Messages sent using UDP user server port 53 (decimal).

Messages carried by UDP are restricted to 512 bytes (not counting the IP
or UDP headers).  Longer messages are truncated and the TC bit is set in
the header.

---------------------------------------------------


Jean-Christophe Smith
Senior Software Engineer
VitalStream
----- Original Message -----
From: "David Hekimian" <davidh at aqueduct.com>
To: <comp-protocols-dns-bind at isc.org>
Sent: Monday, June 03, 2002 11:39 AM
Subject: Cisco Pix drops UDP packets larger than 512 bytes


>
> I've been having some problems looking up specific sites (the MX record
for
> Lycos.Com for example) where the returned packet size is larger than 512
> bytes.
> (Using Dig >8.2.5   'dig -t mx +debug +dn lycos.com @ns3.hotwired.com' )
>
> ---
> Cisco's BugToolkit (BugID CSCds58726) shows the bug as a "Feature" -
> http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=cscds58726
>
> DOC: PIX drops DNS packets of sizes greater than 512 bytes
>
> UDP packets with destination port 53, DNS packets, will be dropped by the
> PIX if the packet size is more than 512 bytes. This is a design
> specification.
> ---
>
> I was under the impression that if a packet is larger then 512 bytes then
> TCP was used. In what instances does BIND switch from UDP to TCP?
>
> ----
> Q. Does this violate a RFC?
> Q. Is this even a desired behavior?
>
> I willing to push Cisco to add a command feature to turn off this
"Feature"
> if not eliminate it completely. I need some backup reasoning (Violates an
> RFC, etc) to build my case (if necessary).
>
> All feedback is greatly appreciated.
>
>
> - David