Would these errors cause email sending issues?
Kevin Darcy
kcd at daimlerchrysler.com
Wed Jan 25 01:10:52 UTC 2006
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
More information about the bind-users
mailing list