We get these quite often. Any idea where could be the problem?
On 10.06.10 09:34, Matus UHLAR - fantomas wrote:
> I run slaves for root zone on two machines, they behave as one of masters
> for each other and for all our resurcive servers providing ixfr
> (I work for an ISP so I think
> it's feasible for us) and I ocationally get these error in log file:
>
> Jun 9 23:11:58 mydb02 named[1427]: general: error: zone ./IN: ixfr-from-differences: failed: new serial (2010060900) out of range [2010060901 - 4157544547]
> Jun 9 23:11:58 mydb02 named[1427]: xfer-in: error: transfer of './IN' from 192.228.79.201#53: failed while receiving responses: out of range
> Jun 9 23:11:58 mydb02 named[1427]: xfer-in: info: transfer of './IN' from 192.228.79.201#53: Transfer completed: 2 messages, 3564 records, 112157 bytes, 1.812 secs (61896 bytes/sec)
>
> Jun 9 23:11:59 mydb02 named[1427]: general: info: zone ./IN: transferred serial 2010060901
> Jun 9 23:11:59 mydb02 named[1427]: xfer-in: info: transfer of './IN' from 192.5.5.241#53: Transfer completed: 3 messages, 3564 records, 125268 bytes, 0.522 secs (239977 bytes/sec)
> Jun 9 23:11:59 mydb02 named[1427]: notify: info: zone ./IN: sending notifies (serial 2010060901)
>
> I wonder what should this mean. I have turned multi-master yes for this zone
> so I expected that BIND should be quiet if the SOA on master is "smaller".
>
> However this looks like BIND notices higher serial on one of masters, but
> then tried to fetch from different master where the SOA hasn't changed yet.
>
> Is ther an bug/issue with multiple masters configuration?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Quantum mechanics: The dreams stuff is made of.
Turn off try-tcp-refresh.
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> In message <20100625060...@fantomas.sk>, Matus UHLAR - fantomas writes:
> > We get these quite often. Any idea where could be the problem?
On 25.06.10 16:10, Mark Andrews wrote:
> Turn off try-tcp-refresh.
Is there better documentation for the try-tcp-refresh option?
While I have no reason not to trust you, I would like to understand the
problem itself. Is looksa likt the tcp refresh would transfer the zone
independently on SOA serial arithmetics.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
With "try-tcp-refresh yes;" the udp retries fail to the master that
is behind. Named does a axfr from that master and you get the message
you see.
The following may also help as it turns on SOA before AXFR for the
ixfr-from-differences case. This has not been tested.
Mark
Index: lib/dns/zone.c
===================================================================
RCS file: /proj/cvs/prod/bind9/lib/dns/zone.c,v
retrieving revision 1.540.2.26
diff -u -r1.540.2.26 zone.c
--- lib/dns/zone.c 2 Jun 2010 01:00:28 -0000 1.540.2.26
+++ lib/dns/zone.c 25 Jun 2010 07:47:41 -0000
@@ -11946,7 +11950,10 @@
} else if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_IXFRFROMDIFFS)) {
dns_zone_log(zone, ISC_LOG_DEBUG(1), "ixfr-from-differences "
"set, requesting AXFR from %s", master);
- xfrtype = dns_rdatatype_axfr;
+ if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_SOABEFOREAXFR))
+ xfrtype = dns_rdatatype_soa;
+ else
+ xfrtype = dns_rdatatype_axfr;
} else if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_FORCEXFER)) {
dns_zone_log(zone, ISC_LOG_DEBUG(1),
"forced reload, requesting AXFR of "
> In message <20100625072...@fantomas.sk>, Matus UHLAR - fantomas writes:
> > Is there better documentation for the try-tcp-refresh option?
> > While I have no reason not to trust you, I would like to understand the
> > problem itself. Is looksa likt the tcp refresh would transfer the zone
> > independently on SOA serial arithmetics.
On 25.06.10 17:49, Mark Andrews wrote:
> With "try-tcp-refresh yes;" the udp retries fail to the master that
> is behind. Named does a axfr from that master and you get the message
> you see.
> The following may also help as it turns on SOA before AXFR for the
> ixfr-from-differences case. This has not been tested.
so named does the AXFR instead of checking SOA when UDP fails?
looks your patch is fixing this.
I have applied the patch (9.7.1) and let you know if it helps.
> --- lib/dns/zone.c 2 Jun 2010 01:00:28 -0000 1.540.2.26
> +++ lib/dns/zone.c 25 Jun 2010 07:47:41 -0000
> @@ -11946,7 +11950,10 @@
> } else if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_IXFRFROMDIFFS)) {
> dns_zone_log(zone, ISC_LOG_DEBUG(1), "ixfr-from-differences "
> "set, requesting AXFR from %s", master);
> - xfrtype = dns_rdatatype_axfr;
> + if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_SOABEFOREAXFR))
> + xfrtype = dns_rdatatype_soa;
> + else
> + xfrtype = dns_rdatatype_axfr;
> } else if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_FORCEXFER)) {
> dns_zone_log(zone, ISC_LOG_DEBUG(1),
> "forced reload, requesting AXFR of "
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.