In <87acjy10p6(_dot_)fsf(_at_)deneb(_dot_)enyo(_dot_)de> Florian Weimer
<fw(_at_)deneb(_dot_)enyo(_dot_)de> writes:
Ok, yeah, check_host() returns None,
I don't think this follows from the specification. "None" is only
returned when the name server returns NXDOMAIN, but not for the
(artifical) NODATA failure (no error, empty answer section).
The spec says that check_host() returns "none" in the following cases:
* When the domain is invalid, malformed or non-existent (Section 4.3)
* When no SPF records are returned (Section 4.5)
NODATA will return no records, and therefore will return "None".
If this is not changed, a very complex procedure is required for
updating SPF records which contain "include" mechanisms, at least if
you want to avoid bounces.
I guess I don't see what the problem is. Can you elaborate on what is
so hard about updating the SPF records?
Okay, I'll give an example. Suppose you just published the following
two DNS records:
spfv1.example.net. IN TXT "v=spf1 a mx ?all"
example.net. IN TXT "v=spf1 include:spfv1.example.net ?all"
There are two authoritative name servers for example.net,
ns1.example.net and ns2.example.net. Assume that ns2.example.net has
not been updated yet (there's always some propagation delay for
updates). A client resolves the example.net/IN/TXT from
ns.example.net, parses it, and looks up the referenced record
spfv1.example.net/IN/TXT. The resolver decides to fetch this record
From ns2.example.net for load-balancing purposes, and gets a NXDOMAIN
error. Hence the SPF check returns PermError, even though this is
just a tempoary error condition.
Well, don't do that.
If you are concerned about this kind of thing, make sure that the
target of the include: is defined and well propogated before you use
it.
The same kind of problem can happen with MX records pointing to new
hosts. This really isn't an SPF specific problem. Hmmm... I guess
the example of MX records can trigger a problem with something like
"v=spf1 mx -all" also.
I don't think it is reasonable for an MTA to issue a 4xx temp-fail
code when the target of an MX record doesn't exist even though it
could just be a propogation delay between name servers. Similarly, I
don't think it is reasonable for SPF checks to return TempError in
these kinds of cases.
-wayne