Would these errors cause email sending issues?

[cgmckeever]

Kevin Darcy wrote:

> 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.

Kevin - thanks, you pretty much clarified everything

The two nameservers are serving the zone - they were listed with the
registrar as the 3 and 4 name server, just not in the zone
config...since been taken care of

> >
> >
> 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.
>

replication was stuck, but none of the changes affected the MX, it was
bascially an difference in one of the round-robin A records (for web,
not mail).

Again, thanks for clarifying if any of these would attribute to mailing
issues.


>
>                                              - Kevin