What happens when DNS messages exceed 512 bytes?
Does DNS switch from UDP to TCP if the response is larger than 512
bytes? In that case, don't we get the same DNS traffic, even if the first
item in an SPF record is a mask that terminates the search?
draft-schlitt-spf-classic-00, Section 3.1.4 - Record Size says that records
that are too long MAY be silently ignored!! This section also implies that
there is a fallback to TCP. ??
The DNS message header has a TC bit (truncated) to indicate that the packet
was truncated at 512 bytes (including headers). Shouldn't this be used
instead of "silently ignored"?
The TXT records for pobox.com are limited to 127 byte strings. This causes
problems for tools like mxtoolbox.com, which "silently ignore" the extra
records. Is there something special about 127 bytes that caused this limit
in the TXT record length? See post by Andy Bakun, Thu, 24 Mar 2005
11:32:40 -0600.
Are long SPF records really necessary? Can we expect large domains like
rr.com, with many subdomains like austin.rr.com to simply delegate all DNS
records to their subdomains, thus keeping them short and simple. The
admins at rr.com could still keep everything centralized if they wished,
but to the outside world, it would appear that austin.rr.com is an
independent mail server with its own DNS records.
There is a question about caching that was answered earlier, but I think
the answer may be wrong, so I'll ask again. Can a DNS server at rr.com
cache the records from austin.rr.com, and thereby minimize the DNS traffic
to its subdomains, or is caching limited to *only* the nameserver at the
host making the query? Section 14.7 Caching, in Stevens TCP/IP Illustrated
says "To reduce the DNS traffic on the Internet, all name servers employ a
cache." The word *all* here makes this a pretty strong statement. Also,
it makes sense that rr.com would cache austin.rr.com. Even with thousands
of subdomains, it would be more efficient for rr.com to handle all the
queries directly.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq'at'gci-net.com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *