ietf-mxcomp
[Top] [All Lists]

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

2004-08-26 16:10:45

On Thu, 26 Aug 2004, Jim Lyon wrote:

In this thread, Rand points out that complicated domains may wish to
publish both SPF1 and SPF2 records, and that this effectively cuts their
maximum record size in half (if they want to fit into a DNS UDP packet,
which they do).  He also points out than these are exactly the domains
that may be pushing the DNS UDP size limits.

While this is an issue, there's a trivially easy workaround: For your
domain, publish very short SPF1 and SPF2 records, that just contain
"REDIRECT=subdomain".  If your SPF1 and SPF2 data are identical, they
can both refer to the same subdomain; if your SPF1 and SPF2 data differ,
they can refer to different subdomains. 

Problem solved.

Actually no, its not. The problem is that because you enter scope identity 
as part of SPF version string, you simple can not refer from one type of 
SPF record to another. So for example if we have
 example.com.   IN   TXT "v=spf1 ip4:10.0.0.0/8 -all"
 example.com.   IN   TXT "spf2.0/pra ip4:10.0.0.0/8 -all"
And assuming that ip4 was to be a lot larger set of records and as Jim
suggested we would want to do it as:
 example.com.   IN   TXT "v=spf1 redirect=_spf.%{d}"
 example.com.   IN   TXT "spf2.0/pra redirect=_spf.%{d}"
And you want to refer them to same record _spf.example.com and publish it as:
 _spf.example.com.  IN   TXT "spf2.0/pra ip4:10.0.0.0/8 -all"
Then the problem is that SPF1 clients will not see since for then only 
valid SPF records are the ones that start with "v=SPF1". And similarly
if it is published as:
 _spf.example.com.  IN   TXT "v=spf1 ip4:10.0.0.0/8 -all"
Then its clients looking for PRA that will not see it since MARID draft
specifies that all MARID TXT records should start with "spf2.0/pra". 

This is fundamental problem with current scoping syntax that one type
of identity record can not refer to another type of identity record
causing necessity to completely duplicate the data in case its the same.

-- 
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net