Would these errors cause email sending issues?

[Kevin Darcy]

cgmckeever wrote:

>I understand that these errors should be fixed (and they have been) - I
>am just trying to learn the magnitude that these errors could cause.
>The issue at hand is that many 3rd part ISP's (aol, comcast) are
>sending bounce/delay/undeliv messages for _good email accounts_:
>
>Bounce message:
>
>From: MAILER-DAEMON at smtp2.foo.com
>Sent: Tue, 24 Jan 2006 13:04:47 -0800
>To: foo.user at foo.com
>
>Reporting-MTA: dns; smtp2.foo.com
>Arrival-Date: Tue, 24 Jan 2006 08:35:14 -0800
>
>Final-Recipient: RFC822; foo at aol.com
>Action: delayed
>Status: 4.2.0
>Last-Attempt-Date: Tue, 24 Jan 2006 13:04:47 -0800
>Will-Retry-Until: Sun, 29 Jan 2006 08:35:14 -0800
>
>DNS Errors:
>
>ERROR: One or more of the nameservers listed at the parent servers are
>not listed as NS records at your nameservers. The problem NS records
>are:
>ns1.foo-dns.net.
>ns2.foo-dns.net.
>
Are these "extra" nameservers in the delegation records actually serving 
your zone with current data? If so, then functionally it shouldn't be a 
problem. Iterative resolvers might follow the delegations down to those 
nameservers initially, but once they cache the smaller NS list, then 
they won't use the "extras" any more until the NS records time out and 
they start all over again. Note, however, that if you're relying on 
NOTIFY to propagate your zone changes quickly, the absence of those NS 
records will cause those "extra" nameservers to replicate more slowly, 
unless you supplement the NOTIFY list using "also-notify" or the 
non-BIND equivalent.

If those "extra" nameservers are serving up a *stale* version of your 
zone, then obviously that can cause problems and you should fix them.

The other possibilities are that a) they are non-responsive (obviously 
that's going to a be a problem), or b) they are responsive, but not 
authoritative for your zone, i.e. "lame" delegations. Those are 
annoying, but generally don't cause any operational problems, as long as 
there are sufficient non-lame nameservers serving the zone.

Regardless of the status of those "extra" nameservers, you *should* make 
the two NS sets consistent. Having them be different leads to confusion, 
inefficiency, and even in the best case, an unpredictably uneven sharing 
of query load.

>ERROR: Your nameservers disagree as to which version of your DNS is the
>latest (2005092923 versus 2005092928). This is OK if you have just made
>a change recently, and your secondary DNS servers haven't yet received
>the new information from the master. I will continue the report,
>assuming that 2005092928 is the correct serial #. The serial numbers
>reported by each DNS server are:
>
>Would these cause mail sending issues??
>
Does the serial # mismatch indicate a replication problem between your 
master and one or more of its slaves? How far apart, chronologically, 
were/are the 2005092923 and 2005092928 versions of the zone? More than 
the REFRESH setting in the SOA? You should check whether replication is 
"stuck" or not. Maybe one or more of the slaves is serving stale data. 
That could cause mail delivery problems, if the MX records and/or 
associated A records have been changed in the recent past.

                                                                         
                                             - Kevin