On Fri, 2005-03-25 at 06:43, David MacQuigg wrote:
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"?
Geez, I'm starting to feel old :) Back in the, er, day, there was a
big hubabaloo over what happens with larger DNS responses. My
understanding (from having read this list for a long time and some minor
research that resulted from those previous discussions, so I could be
grossly misinformed) is that when the TC flag is set, the resolver is
supposed to switch to TCP (baring implementation of EDNS, according to
Stephane Bortzmeyer). This is all well and good for modern and properly
implemented resolvers, but runs into a snag when:
* those who configure firewalls think that DNS only operates over
UDP port 53 and block TCP port 53, so the resolver on the client
can not effectively use TCP
* some older calls to resolve DNS entries on win32 use WINS to
communicate with local win32 name servers, which are apparently
limited in their implementation (some might call this "buggy").
(this was also an issue, if memory serves, in that win32 would
be unable to resolve new record types, and thus was viewed as
more reason to use the already established (and more verbose)
TXT rather than a shiny, new, compact, binary-over-the-wire SPF
RR).
I think the latter was blown out of proportion (and a lot of time wasted
on it) because of concentration on the fact that SenderID that would be
implemented closer to the MUA, the market of which is largely win32
code. I vaguely remember something about WinME and Win98 machines not
being able to handle some of the outlier SPF TXT records, but this was
kind of a moot point to the SPF crowd (read: non-SenderID crowd) because
if you're running your MTA on either of those, you've got other
problems.
This is all in the list archives, which are a good deal more accurate
than my memory. I want to say that between March and July of 2004
should get you some good discussion. But this list was much more active
back then, so happy wading!
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.
Using ethereal, it does not appear that the part of the record beyond
127 bytes is "another record". It appears that the longer TXT response
string is being split into two strings (both of which are in the same
answer portion of the response). It is split at 127 bytes because they
are prefix-length encoded. I suspect 127 is because the length byte is
signed (51% of all strings have a, ahem, negative length, you know ;)
). Here's the packet dump:
+ Frame 4 (375 bytes on wire, 375 bytes captured)
Internet Protocol, Src Addr: 172.27.1.1 (172.27.1.1),
Dst Addr: 172.27.1.194 (172.27.1.194)
User Datagram Protocol, Src Port: domain (53), Dst Port: 35835 (35835)
Domain Name System (response)
Transaction ID: 0xd81d
Flags: 0x8180 (Standard query response, No error)
Questions: 1
Answer RRs: 1
Authority RRs: 5
Additional RRs: 0
Queries
Answers
pobox.com: type TXT, class IN
Name: pobox.com
Type: TXT (Text strings)
Class: IN (0x0001)
Time to live: 59 minutes, 25 seconds
Data length: 195
+ Text: v=spf1 mx mx:fallback-relay.%{d} a:webmail.%{d}
+ a:smtp.%{d} a:outgoing.smtp.%{d}
+ a:discard-reports.%{d} a:discards.%{d} mx:stor
+ Text: e.discard.%{d} a:emerald.%{d}
+ redirect=%{l1r+}._at_.%{o}._spf.%{d}
Authoritative nameservers
pobox.com: type NS, class IN, ns ns5.rightbox.com
... truncated ...
I've inserted newlines and indented the Text content to make it easier
to see. The lines prefixed with + are the important ones. Note the
total bytes in the Frame line, well under 512. Each of those Text:
lines have a length byte before them (not shown, but it appears in the
byte dump), 127 and 66 respectively. The Data Length value seems to
include two length bytes in the 195 count.
From this, it seems that mxtoolbox.com is not correctly interpreting the
response it is getting. (note that the above capture is from my desktop
(using dig) to my local named instance, and I suppose the interaction
between my local name server and pobox's name servers could be
different).
Are long SPF records really necessary?
If Radu doesn't just have a Cassandra Complex (for the record, I believe
him that there is cause for concern, but the predictions seem overly
dire), then they may be, as complex network setups expressed as SPF
mechanisms may compile to a longer TXT record that, while doesn't result
in as many queries, is significantly longer in byte count, thus perhaps
causing fall back to TCP (which may not work).
But, you'll notice that this is why Radu's SPF compiler compiles to
multiple short records and chains them using redirect=. Unfortunately,
this increases the query count in the average case, so we're closer to
where we started. I'd like to think that this is still being hammered
out.