spf-discuss
[Top] [All Lists]

Re: Updating SPF type99 and TXT RR's: Simultaneity is not guaranteed.

2005-08-11 11:27:59
In <87wtmstr83(_dot_)fsf(_at_)mid(_dot_)deneb(_dot_)enyo(_dot_)de> Florian 
Weimer <fw(_at_)deneb(_dot_)enyo(_dot_)de> writes:

Most of the problems described in that document are things you have to
be careful about when updating DNS records in general.  They are not
specific to SPF.  You have to be careful when updating things like NS
and MX records to make sure you don't have any dangling DNS pointers,
even when you aren't do anything with SPF.

Sorry, Wayne, this is just not true.

If I have a dangling NS pointer, my zone continues to work just fine.
I might receive some harassing mail which instructs me to fix the lame
delegation, but that's all.


Say you have

foo.org.      NS  ns1.bar.com.
foo.org.      NS  ns2.bar.com.

ns1.bar.com.  A   1.2.3.4
ns1.bar.com.  A   2.3.4.5


Now bar.com needs to switch networks, so they publish:

ns1.bar.com.  A   9.8.7.6
ns1.bar.com.  A   8.7.6.5


Until the original A records for the bar.com name servers timeout, you
will get *zero* resolutions to the foo.org comain.  Not just
complaints about lame name servers, but no results at all.


                             Similar for MX records.  If they are
temporarily unavailable (or the host is firewalled), mail is queued,
or other MX records are tried.

Say you have:

foo.org.         MX  mail1.foo.org.
mail1.foo.org.   A   1.2.3.4

Now, you decide to switch mail servers, so you delete mail1.foo.org
and create smtp-in.bar.com.

foo.org.         MX  smtp-in.bar.com.
smtp-in.bar.com. A   3.4.5.6


Until smtp-in.bar.com gets propogated to the secondary name servers,
you will get NXDOMAIN errors and email will be rejected.  Also, due to
TTL differences, it is possible to have the old MX of mail1.foo.org be
remembered, while mail1.foo.org is returned as an NXDOMAIN.

Again, your email will be rejected.

Yes, if you have secondary MXes, it can help, but not if you switch
them both.


The answer is:  Don't do that!

There needs to be a transition period, for all of these cases.  You
need to make sure that the old IP addresses and domains still exist
and function correctly until such time as everything is using the new
information.   This is no different for SPF records as anything else.


SPF is different.  The specification *explicitly* requires that
certain problems which can be caused by DNS convergence are flagged as
PermError.

And I don't recommend rejecting email on PermError.  The old SPF specs
(mengwong-spf-0[01]) said that PermError (then known as Unknown) MUST
be treated as if there were no SPF records published.   The best I
could do with the current spec is not say anything in the spec about
what to do with PermError.  (I lost the vote.)


The problem that shew pointed out is something that can *not* be fixed
with standard DNS update techniques.  That is why it is different and
critical. 

Temporarily publishing just one record seems to do the trick.

Yeah, I guess.  However, it doesn't seem to make much sense to freely
allow SPF implementations to only query one, of the implementation's
choice, but then if you query both, you have problems.  I think it
would be best just to let SPF implementations choose.


-wayne


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