On Fri, 14 Jan 2005, Julian Mehnle wrote:
Alright, after all this heated discussion of the zone cut defaulting
algorithm in the SPF specification, I'd like to make two alternative
proposals on how to make SPF better deployable without SPF clients having
to perform zone cut lookups:
1. Generally require a MAIL FROM domain to have an MX record.
Motto: Only a domain that can receive mail should be sending out mail.
Basically, this would just be a rude deprecation of the implicit MX
rule, with the effect that domains without an MX record would not have
to specify an SPF record. This would be a gross incompatible change
to SPF and the e-mail system in general, so you probably are not going
to like this. :-|
I will not dismiss it immediately but I don't think this is the way to go.
2. Like the name-server-side special handling of NS and SOA records, give
name-server-side special handling to new SPF-type records.
Specify the new SPF RR type such that name servers should perform the
zone cut defaulting internally. Some would say this is a problem
because it would require the new RR type to be implemented in name
servers before the feature could be used. I would say this could be
an incentive to actually get the new RR type implemented. :-)
Above will not work for TXT records and I think it maybe blocked by DNS
people for proposing such special record (or at least delayed).
I have a proposal similar to above. First we do need to recognize and
specify that making spf records available for all hosts that send email
is responsibility of the domain owner and that wildcards is a tool for
domain dns administrator.
Now as far as proposal:
1. We do it the right way and propose dns extension for '**' wildcards
which are matched for existing hosts that do not specifically have
certain RR (in our case we care about SPF and TXT RRs)
2. We specify that if there was NODATA/NOERROR response and the same
dns response contained AUTHORITY section with SOA then spf client
SHOULD manually try to check for '**' record at the root of that
authority zone (as found in SOA).
I have done survey yesterday and found that all of the dns servers that
have at least 0.1% share provide AUTHORITY section for NODATA. John Levine
noted that while that may be true, the djb cashing-only server will not
provide AUTHORITY section. So I recognize that means above algorithm will
not work 100% of the time but even without it because in 95%+ of the places
this system would work there would not be much incentive for spammer to
try to forge domains like that. Plus as dns servers themselve are updated
with direct support for new wildcard type, the extra lookups would no
longer be done.
The good thing about above is that the extra lookups will no longer be
done once the new wildcard record is directly understood by the server,
so extra lookups will get depreciated on their own.
P.S. Here is my survey of what DNS Servers send when looking up RR type
that is not present (I used HINFO) for existing host. I looked at all the dns
servers that were specified as > 0.1% share at http://mydns.bboy.net/survey/
---------------------------------------------------------------------------
Server Type Name Percent Tested Server & Version Authority Section
---------------------------------------------------------------------------
BIND9 70.1% SOA
BIND8 BIND 8.3.0 SOA
TinyDNS (djb) 15.5% TinyDNS 1.0.5 @spf.pobox.com SOA
Microsoft DNS 6.2% Windows2000 SOA
MyDNS 2.8% @ns1.itmom.com SOA
PowerDNS 2% PDNS 2.9 @dns-eu1.powerdns.net SOA
authority section listed www.powerdns.com
Simple DNS+ 1.25% @dns1.jhsoft.com SOA
Pliant DNS 0.3% @openpack.org SOA
authority section listed www.openpack.org
Simple DNS+ 1.25% @dns1.jhsoft.com SOA
Pliant DNS 0.3% @openpack.org SOA
authority section listed www.openpack.org
UltraDNS 0.15% @udns1.ultradns.net NS
NSD 0.2% NSD 1.2.3 @b.nic.fr SOA
---------------------------------------------------------------------------
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/