spf-discuss
[Top] [All Lists]

Re: Why TXT zone record location for SPF and Sender ID data are domain default ( @ TXT "data") ?

2004-07-08 10:19:15
[...]

We have considered this idea in the past, and chosen not to
proceed for a number of reasons.  The strongest reasons are:

if we did this we would use an underscore ---
"_spf.domain.com" and enough people believe that underscores
are not permitted in DNS to cause significant friction.

What the point ?
You do not wish to have congentions by using underscores,
but instead of this put data in default record - thich will definitely have
congentions.

You are hitting completely different sides of congention problems - most
likely or never.
Real solution somethere in middle - it's unlikely user will have "spf" TXT
record.

if we did this, it would be difficult to support wildcard
subdomains.

It's not SPF issue.And not DNS client specification issues (I'm unsure about
on server to server zone transfers with wildcards)

It's DNS server software issues.

I preffer BIND and other DNS servers support something like
spf.* TXT "v-spf1: our data"
Actualy this already can be done by introducing additional record type, but
IMHO, this is not reasonable.

Consider following - if you have wildcard DNS A record and need to use both
www and ftp - you must put them on same IP.

I.e. this is impossible to have
www.* IN A 10.10.10.1
ftp.*   IN A 10.10.10.2

It's limitations of DNS server software to support wilcard sub-records.
I do not support your ideas to create flawed specification simply becouse of
flawed software currently existing.
Once you will wrote this in specs - you will be be never able to correct
this (but software can evolve)

For more on the wildcard issue, see MARID discussions at
http://www.imc.org/ietf-mxcomp/mail-archive/msg01815.html>

I've checked this. Add my vote to use prefix as something in middle of
underscores and default record.

P.S> "nslookup -q=any domain.com" can fail or be truncated becouse of SPF
domain default TXT record.
This can have much bigger software compatibity burden - as all client (not
server) software must be updated.

IMHO, Your current design do not follow robustness principle.
You support cool idea of "exists" (DNSBLs) but do not wish to support
wildcard sub-records.
Wildcard domains are not so widely used and admins serving wildcards domains
(most likely ISPs) will be able to update software.
Most actively used DNS server - BIND is updating every year or two becouse
of security issues.
SPAM is much bigger issue compared to administrative burden to update
_select_ wildcard DNS servers.
Top email senders from senderbase.org do not need wildcards or can upgrade
software.

Thanks for listening me,
--
Andriy G. Tereshchenko
TAG Software
Odessa, Ukraine
http://www.24.odessa.ua


<Prev in Thread] Current Thread [Next in Thread>