Re: Bind 9.6.1: skipping zone transfer, but why ?
At Wed, 22 Jul 2009 15:56:38 +0200, Jan Hansen bi...@nhl-data.dk wrote: As I wrote in the post Master is unreachable (cached), I've switched to windows server 2003, which currently *seem* to have a positive effect. I haven't seen the behaviour yet after the switch, but Ian Tait sees this behaviour on 2003. Is it OS specific, or does it affect both 2003/2008? As far as I'm informed, much of the network stack is new in 2008/vista and forward, which maybe could be related to this problem? I don't know if this is version specific. Note that this bug is triggered due to a failure of zone transfer. So you may just be lucky when you didn't see the problem. When will this fix be out in a release? 9.6.2, perhaps? or what is the roadmap for that kind of things? It will appear in 9.6.2. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.6.1: skipping zone transfer, but why ?
At Mon, 20 Jul 2009 16:13:03 +0100, Ian Tait ia...@thoughtbubble.net wrote: I see exactly this problem too on windows 2003. Lookups happen normally after this behaviour occurs though. Restarting bind cures the problem. I haven't bothered to debug the issue as yet :-) We've found a bug that can cause this problem. We're working on a complete fix to the problem, but a workaround patch copied below may work for you in the mean time. p.s. this is a Windows specific bug. --- JINMEI, Tatuya Internet Systems Consortium, Inc. Index: zone.c === RCS file: /proj/cvs/prod/bind9/lib/dns/zone.c,v retrieving revision 1.483.36.7 diff -u -r1.483.36.7 zone.c --- zone.c 17 Jun 2009 04:53:57 - 1.483.36.7 +++ zone.c 20 Jul 2009 19:41:18 - @@ -11004,6 +11004,8 @@ isc_result_t result; isc_uint32_t seconds = isc_time_seconds(now); + return; + REQUIRE(DNS_ZONEMGR_VALID(zmgr)); locktype = isc_rwlocktype_read; ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.6.1: skipping zone transfer, but why ?
At Mon, 20 Jul 2009 12:41:24 -0700, JINMEI Tatuya jin...@isc.org wrote: We've found a bug that can cause this problem. We're working on a complete fix to the problem, but a workaround patch copied below may work for you in the mean time. Sorry that patch was incorrect. Copying the correct one. --- JINMEI, Tatuya Index: zone.c === RCS file: /proj/cvs/prod/bind9/lib/dns/zone.c,v retrieving revision 1.483.36.7 diff -u -r1.483.36.7 zone.c --- zone.c 17 Jun 2009 04:53:57 - 1.483.36.7 +++ zone.c 20 Jul 2009 19:42:09 - @@ -11032,6 +11032,8 @@ isc_uint32_t last = seconds; unsigned int i, slot = UNREACH_CHACHE_SIZE, oldest = 0; + return; + REQUIRE(DNS_ZONEMGR_VALID(zmgr)); RWLOCK(zmgr-rwlock, isc_rwlocktype_write); ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.6.1: skipping zone transfer, but why ?
Chris Buxton wrote: On Jun 30, 2009, at 6:15 AM, bind9 wrote: 1) skipping zone transfer as master 213.173.250.146#53 (source 0.0.0.0#0) is unreachable (cached) seem to indicate that the slave has cached a knowledge about the master being unreachable. It isn't. I can nslookup on the master from the slave just fine. What is wrong? The slave is caching, for some length of time set in the source code (an hour? something like that), that the master is unreachable for zone transfers. 2) what causes transfer of '3yhta.dk/IN' from 213.173.250.146#53: failed to connect: connection refused ? There is no evidence of connection refused in the masters log, so where could this come from? The connection refused error means that nothing is listening at that port on that addresses. That means that either that address was not configured to listen on that address or the server has gone down. The master is unreachable over TCP. The port has gone deaf. We see this on some operating systems and not others. (We don't work much with BIND on Windows, so we hadn't seen the issue on that OS.) Basically, when the port is not used for a while, it looks like the OS shuts down the listener without telling the service. No, Windows doesn't do that. It is no different from a Unix O/S. I have no idea what you mean by the listener here or the service, but on Windows the service is only involved with getting the server running and does not know or care about what IP addresses and ports get used if they get used at all. This is no different from Unix. Danny ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.6.1: skipping zone transfer, but why ?
On Jun 30, 2009, at 6:15 AM, bind9 wrote: 1) skipping zone transfer as master 213.173.250.146#53 (source 0.0.0.0#0) is unreachable (cached) seem to indicate that the slave has cached a knowledge about the master being unreachable. It isn't. I can nslookup on the master from the slave just fine. What is wrong? The slave is caching, for some length of time set in the source code (an hour? something like that), that the master is unreachable for zone transfers. 2) what causes transfer of '3yhta.dk/IN' from 213.173.250.146#53: failed to connect: connection refused ? There is no evidence of connection refused in the masters log, so where could this come from? The master is unreachable over TCP. The port has gone deaf. We see this on some operating systems and not others. (We don't work much with BIND on Windows, so we hadn't seen the issue on that OS.) Basically, when the port is not used for a while, it looks like the OS shuts down the listener without telling the service. Chris Buxton Professional Services Men Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind 9.6.1: skipping zone transfer, but why ?
Hi list, I'm currently developing a management application that will run on each of our nameservers and take care of domain creation, deletion and updates. Sort of remote controlling Bind via commands entered in a database. My setup is one master and three slaves, all running windows (2008, 3x2003 respectively) and all running Bind 9.6.1. As an example: an update to a zone requires the master to re-generate the zonefile (with an increased serial) and then reload that particular zone. This will cause the master to issue notify-messages to the three slaves, which in turn will retrieve the updated zone file. All is well and good. This mostly works, but at times the slave servers seem to get into a my master server is unreachable-mode, which I can't get them out of unless I restart the ISC Bind service. Please take a look a the log below (from a slave). In line 1, the client receives a notify from the master. This is a create-scenario, so the master has just got a new _zones.conf and zonefile, and a bind reconfig command. However, the slave has not yet create its new _zones.conf file, so it isnt authorative yet. Then, a new _zones.conf is generated on the slave , and a bind reconfig is issued (line 2). Bind loads the new config file, but is skipping zone transfer as the master apparently is unreachable. 30-jun-2009 14:43:43.828 notify: notice: client 213.173.250.146#10182: received notify for zone '3yhta.dk': not authoritative 30-jun-2009 14:43:44.718 general: info: received control channel command 'reconfig' 30-jun-2009 14:43:44.718 general: info: loading configuration from 'C:\WINDOWS\system32 \dns\etc\named.conf' 30-jun-2009 14:43:44.718 general: info: using default UDP/IPv4 port range: [1024, 65535] 30-jun-2009 14:43:44.718 general: info: using default UDP/IPv6 port range: [1024, 65535] 30-jun-2009 14:43:44.718 network: info: no IPv6 interfaces found 30-jun-2009 14:43:44.781 general: info: reloading configuration succeeded 30-jun-2009 14:43:44.781 general: info: any newly configured zones are now loaded 30-jun-2009 14:43:44.781 general: info: zone 3yhta.dk/IN: refresh: skipping zone transfer as master 213.173.250.146#53 (source 0.0.0.0#0) is unreachable (cached) Succeeding attempts to reload the zone, retransfer the zone yields the same skipping zone transfer as master 213.173.250.146#53 (source 0.0.0.0#0) is unreachable (cached) error, and a service restart caused this to show up: 30-jun-2009 14:48:22.828 xfer-in: error: transfer of '3yhta.dk/IN' from 213.173.250.146#53: failed to connect: connection refused 30-jun-2009 14:48:22.828 xfer-in: info: transfer of '3yhta.dk/IN' from 213.173.250.146#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.937 secs (0 bytes/sec) I then restarted BOTH the service on the master and the slave, and the slave then successfully transferred the zone data, but my questions are: 1) skipping zone transfer as master 213.173.250.146#53 (source 0.0.0.0#0) is unreachable (cached) seem to indicate that the slave has cached a knowledge about the master being unreachable. It isn't. I can nslookup on the master from the slave just fine. What is wrong? 2) what causes transfer of '3yhta.dk/IN' from 213.173.250.146#53: failed to connect: connection refused ? There is no evidence of connection refused in the masters log, so where could this come from? Thanks for your time in advance :o) Best regards Jan Hansen s ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
