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.
(This isn't true because of a bug in a widely used resolver which
fiddles with TTLs in this scenario, but let's ignore that.)
The difference between your scenario and mine is that I specifically
wrote about "*a* dangling NS pointer", and you present something with
*only* dangling NS pointers.
In the SPF case, if there's *one* "include:" that fails with a
NXDOMAIN or NODATA error, the entire record is PermError-ed, even if
it contains useful data.
Yes, if you have secondary MXes, it can help, but not if you switch
them both.
I can list all of them temporarily. Properly configured mail servers
do not care if they are the lowest-numbered MX or not, for exactly
this reason. (Yes, I learnt that the hard way.)
In fact, this is the way to handle my other example: temporarily list
both mail.enyo.de and mail.lf.net. So I need something better still.
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.
No, the way in which "include" error recovery is specified makes SPF
unnecessarily fragile. SPF also has a tendency to turn things that
would be 4xxs in the other direction (e.g. change in IP address of MX)
into 5xx. (This is a problem that is inherent to the DNS-based
mechanisms, of course, and to some extent even deliberate and
unavoidable.)
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.)
This is very unfortunate. *sigh*
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.
Implementation choice is not the real problem, it's the mandatory
consistency check if the implementation is confronted with both TXT
and TYPE99 records.