In <7518(_at_)rama(_dot_)pamho(_dot_)net> "Roger Moser"
<Roger(_dot_)Moser(_at_)rama(_dot_)pamho(_dot_)net> writes:
If no matching records are returned for the <domain;>, the SPF client
MUST find the Zone Cut as defined in [RFC2181] section 6 and repeat
the above steps. The <domain>'s zone origin is then searched for SPF
records. If an SPF record is found at the zone origin, the <domain>
is set to the zone origin as if a "redirect" modifier was executed.
I no longer find this a good idea without having a "match_subdomains=yes"
modifier as specified in spf-draft-200406. The reason is following example:
Back in December, in response to some of William's comments on the
spf-classic I-D, I wrote:
| > Ok. When did we decide that there is a consensus that SPF will support
| > zonecut spf records for subdomains?
|
| Zonecuts are in spf-draft-200406.
|
| I admit that zonecuts are not widely implemented and this is one thing
| that I could see being removed.
I am leaning more and more toward removing zone cuts from the I-D.
The DNS experts on the IETF namedroppers list generally hate the idea,
but I think it has distracted them from complaining about the use of
TXT RRs. (Ok, the use of TXT RRs by SPF was debated on namedroppers
last fall for another I-D they are considering, so they may have just
gotten tired of it. I stayed completely out of the that debate. ;-)
The advantages of zone cuts are:
* A domain owner can easily put one SPF record in their zone(s) which
will cover all hosts, even those not involved with email.
* Zone cuts allow the domain owner to explicitly say that non-existent
subdomains of their domain should never be used.
This isn't so much of a problem for the MAIL FROM identity, since
lots of MTAs already allow you to reject mail from hosts that don't
exist, but this *is* a problem with the HELO identity. There is
just too much legitimate email that comes from MTAs that give bogus
HELO domains for many people to reject email from them. A zone cut
SPF record lets those domain owners that know that they have their
MTAs in working order to tell email receivers that other MTAs
claiming to be from them are not legitimate.
The basic problem is that the HELO domain has never really been used
for anything important and therefore most MTAs don't bother
validating it. As a result, there is a lot of badly configured HELO
domains out there which will break if they are used.
* Many domain owners have *assumed* that publishing an SPF record at
the top of their zone will cover all of their zone.
The disadvantages of zone cuts are:
* Extra DNS lookups. This is especially a problem for those that have
not published SPF records at all. Checking the zone cut will cause
the most DNS lookups for those domain owners that haven't opt-ed in
to SPF and, in effect, requires them to opt-out.
* Zone cuts are not widely supported in current SPF implementations.
I've said that I'm trying to document the de-facto SPF standard, and
zone cuts are not part of the de-facto standard.
* Finding zone cuts is not well defined. Few other applications even
try to find a zone cut and there are some who argue that zone cuts
should be invisible, that trying to find a zone cut is a layer
violation. More importantly, while RFC2181 describes what a zone
cut *is*, it does not describe how to find one by querying the DNS.
The basic problem is that the zone cut has never really been used
for anything important and therefore most name servers don't bother
validating it. As a result, there is a lot of badly configured zones
out there which will break if they are used.
* zone cuts have not always been a part of the SPF spec and domain
owners have published records that don't work well with zone cut
usage.
Alternatives to the zone cut:
* The only alternative that has really been suggested is that SPF
records should simply be returned for all hosts (domains/subdomains
with A or MX records).
This doesn't allow domain owners to repudiate non-existent domains,
which would be very useful in the cases of HELO domains.
This is a PITA for large domains with lots of subdomains in them,
for example ISPs. I think it is very unlikely that name server
vendors (bind, djbdns, enom, etc.) are going to change their
software to automate this process.
Please let me know your thoughts on this subject.
-wayne