ietf-mxcomp
[Top] [All Lists]

DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe)

2004-08-25 20:44:12

With regards to the Sender ID record being published as a TXT record for
the FQDN hostname (in a TXT record for domain.com), real world usage is
already showing that this dataspace is becoming populated with spfv1
records deployed by many sites in order to increase deliverability to
certain very large ISPs and others.  By publishing spfv2/pra records in
the same dataspace (domain.com), we are effectively halving the usable UDP
packet size for responses, since a TXT query for domain.com will try to
return *all* TXT records for domain.com in one record.

Real world deployment experience is that most network firewall operators
do not allow DNS queries over TCP except to trusted secondaries.  The
indicated wishes of large ISPs is that they do not want to have to fall
back to a TCP connection anyways for verifying incoming mail because it
will cause too much overhead.

My concern was mollified by people pointing out that "even AOL's SPF
record can fit in 160 bytes, so they can almost squeeze three parallel
records in to the same TXT UDP response packet."  In the past couple of
weeks I have talked to a few *major* .com sites (financial, media,
consumer) whose real-world outbound architecture is waaaaaaaay more
complex than AOLs.  In particular, with the number of global sites they
run, the number of third party delivery services they contract with, and
their general focus being on running their business instead of their
email, many of these large companies are going to have trouble fitting a
single SPF-like record in a UDP-sized query, let alone fitting it in half
that size.

My concern for Sender ID is that since SPF has already claimed the FQDN
TXT dataspace for itself (and since SPF is seeing parallel adoption
regardless of where Sender ID goes), trying to stuff a second Sender ID
record in the same data space will be problematic for some, and if we
ever try to evolve this to a third version then it will *never* fit.

The solution I would suggest is to put spfv2/pra records in a sub-domain
such as _marid.company.com.  While it would be nice to recommend that
people begin allowing TCP DNS queries, it is unlikely that the highest
volume sites would ever want to implement such.

This is a concern that has been voiced to me by several major sites that
are exactly the same set of sites we use as examples for where we need to
stop phishing from.  They are most likely going to publish *both* spfv1
and spfv2/pra records, and their initial investigation of their email
architectures has indicated that those records are going to be pushing
this real-world 240-byte limit (a 480 byte effective UDP packet split in
two)

-Rand