At 05:33 PM 4/1/2005 -0800, William Leibzon wrote:
On Sat, 2 Apr 2005, Frank Ellermann wrote:
David MacQuigg wrote:
Is there any reason not to set up subdomains like
_SPF1.<domain> ?
Discussed on mxcomp (the former MARID list) many times. One
problem is obvious, if you can do something with the records
for FQDN, it doesn't necessarily mean that you can also do
something with _SPF.FQDN And the DNS crowd hated the idea.
Lets be clear about something. "DNS crowd" hated the idea of (ab)use of
TXT records and did not think that prefix addressed their concerns (they
are quite right). However when presented with choice between no prefix and
prefix they all agree that prefix is slightly more prefirable and less
likely to lead to collisions.
At mxcomp split was even 50/50 for those who wanted and did not want it
when this question was raised directly by group chair and almost every
technically sound argument was for prefix, however large number of SPF
folks there did not want it and main reasons presented were that their
registrar or dns provider did not support "_" in subdomains.
Another problem is less obvious, it doesn't work well with
wildcards. For almost all foobar.claranet.de (excl. names
like pop, www, and a few other exceptions) you get the same
wildcard policy as for xyzzy.claranet.de
It was shown after some people said that prefix could help with wildcard
issues, that using prefix does not help. However saying that they do not
work well with wildcards is wrong - they work no better or worse then no
prefix.
Of course this also covers _SPF.foobar and _SPF.xyzzy, but
the potential advantage of the prefix is lost.
No, potential is still there as they provide for less chance of collisions.
Please check the mxcomp archive for more details and better explanations.
Very large thread started by this post will give you an idea of the issues
and following discussions on where prefixes do and do not help:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03641.html
when the query for _SPF1.<domain> arrives at <domain>, that
the nameserver at <domain> will be smart enough to return
the final result.
Impossible unless you can get this through dns IETF WG and as I noted this
takes 5 years (and it must be general dns feature because same dns zone
maybe XFER to dns server that runs different software and all servers must
function the same, in theory at least).
I was not able in two hours to make sense of the discussions in mxcomp on
this issue. These long threads degenerate into mind-boggling trivia and
side issues, and there is no summary at the end. Also, I don't want to
repeat the same long discussions on this list.
What I'm assuming now is that there are some operational difficulties with
_SPF1.<domain>, but nothing insurmountable, and we should use it if there
isn't a better way to avoid competition with other methods over the 450
bytes allowed in a DNS record.
It's a shame there isn't a summary of these discussions. Maybe we should
consider doing that for this mailing list. You can find my stuff at
http://purl.net/net/macquigg/email If you want to see a summary of my
current thoughts on authentication headers, you don't have to wade through
tons of prior postings. It would be nice if we had a wiki site where we
could find *everyone's* summary statement on various issues. I don't have
a wiki site to offer, but if there is one available somewhere, I will be
glad to set up the top page, listing at least the issues I've been involved
in. Wikipedia is a possibility, but I find their version control very
burdensome, and also this site is intended for finished articles, tracking
revisions, etc., not just a community scratchpad like what we need.
-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *