In message <7917527.VmCQD3a6Q3@scott-latitude-e6320>, Scott Kitterman writes:
On Wednesday, August 21, 2013 23:32:33 Mark Andrews wrote:
I object to the removal of the SPF record.
This is not a shock. You were in the rough when we discussed it in the WG
too.
Name servers already have access controls down to the granuality
of TYPE. If this draft proceeds as currently described it is forcing
name server vendors to access controls at the sub TYPE granuality.
It's primarily an issue for applications. To the DNS, it's exactly what it
is, a TXT record.
No. It isn't. By overloading TXT you prevent thing like this which
existed before SPF was even dreamed up.
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net SPF
grant key-two domain example.net ANY
};
or
update-policy {
grant key-one subdomain example.net ANY
grant key-two domain example.net TXT
};
Overloading a type is bad on so many levels which is why it was
argued that SPF needed its own type. TXT is good for prototyping
and that is about all.
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net TXT/v=spf1
grant key-two domain example.net ANY
};
update-policy {
grant key-one subdomain example.net ANY
deny key-two domain example.net TXT/v=spf1
grant key-two domain example.net TXT!v=spf1
};
With SPF lookup first I can specify the SPF policy using SPF and
leave TXT free for other uses without having to worry about the
records being misinterpeted.
Unless you have some specific reason to be concerned about accidentally
starting an unrelated TXT record with "v=spf1 ", I can't imagine you don't
have more important things to worry about. This being a "problem" is a great
theory, but it just doesn't happen in practice.
It's about being able to hand someone update control and not having to
worry about them stuffing up the SPF records.
SPF validators MUST NOT proceed to a TXT lookup on SERVFAIL for SPF.
This is similar to not proceeding to A/AAAA lookups on MX lookup
failures.
Except that it's quite common for a SERVFAIL on TYPESPF to occur for a domain
that has an actual SPF record due to various operational issues. SERVFAIL on
type SPF doesn't reliably tell you anything about what a type TXT lookup
would
produce. So it's similar, but only superficially so.
And the worst that happens is that you let some *additional*
potentially spoofed email through. This WG seems to treat this
as a catastrophic errror when it isn't. This whole debate is
because this working group treats not stopping one additional
forgery as a catastrophic errror.
Note also that it will be the publishing site to blame for having
a non RFC 1034 compliant server (it didn't respond to SPF queries)
or misconfigured zone (returns wrong SOA in the negative response
which can't happen when they have a SPF record).
I would also suggest that there be a sunset date published for the
use of TXT for SPF.
Do you also suggest creation of an Internet police force to enforce this?
What would be be mandatory minimum sentence?
You just code the cut off date into the code that does the verification
and stop making TXT queries. You code the date into the code that
checks for missing SPF records and change the complaint.
Scott K
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org