Well I was able to duplicate the error on another machine that is not Gentoo (RH
Enterprise) so the idea that it is Gentoo specific is not true:

Here is generally what is happening (in the debug messages).
On the systems that work this is what is shown:
Feb 20 10:13:18.083 client 192.168.1.7#51283: update 'samplezone.com/IN'
approved
Feb 20 10:13:18.083 client 192.168.1.7#51283: updating zone 'samplezone.com/IN':
adding an RR
Feb 20 10:13:18.083 writing to journal
Feb 20 10:13:18.086 client 192.168.1.7#51283: send
Feb 20 10:13:18.086 client 192.168.1.7#51283: sendto
Feb 20 10:13:18.086 client 192.168.1.7#51283: senddone
Feb 20 10:13:18.086 client 192.168.1.7#51283: next
Feb 20 10:13:18.086 client 192.168.1.7#51283: endrequest
Feb 20 10:13:18.086 client @0xb6b2050: udprecv
Feb 20 10:13:18.087 zone_timer: zone samplezone.com/IN: enter
Feb 20 10:13:18.087 zone_maintenance: zone samplezone.com/IN: enter
Feb 20 10:13:18.087 zone samplezone.com/IN: sending notifies (serial 2003010106)
Feb 20 10:13:18.087 dns_adb_destroyfind on find 0x1991c1c8
Feb 20 10:13:18.112 dns_adb_destroyfind on find 0x1991c1c8
Feb 20 10:13:18.112 dns_adb_destroyfind on find 0x1991c1c8
Feb 20 10:13:18.112 dns_adb_destroyfind on find 0x1991c1c8
Feb 20 10:13:18.112 zone samplezone.com/IN: sending notify to 192.168.1.11#53


This system sends the notifies and everything.

Now on this system the notifies are never sent.
Feb 20 10:10:55.304 client 192.168.1.7#65030: update 'samplezone.com/IN'
approved
Feb 20 10:10:55.304 client 192.168.1.7#65030: updating zone 'samplezone.com/IN':
adding an RR
Feb 20 10:10:55.304 writing to journal
Feb 20 10:10:55.306 client 192.168.1.7#65030: send
Feb 20 10:10:55.306 client 192.168.1.7#65030: sendto
Feb 20 10:10:55.306 client 192.168.1.7#65030: senddone
Feb 20 10:10:55.306 client 192.168.1.7#65030: next
Feb 20 10:10:55.306 client 192.168.1.7#65030: endrequest
Feb 20 10:10:55.306 client @0xc14ae88: udprecv
Feb 20 10:10:55.306 zone_timer: zone samplezone.com/IN: enter
Feb 20 10:10:55.306 zone_maintenance: zone samplezone.com/IN: enter


What can be preventing the notify from being sent?
Any ideas why this would happen only on certain systems?

Thanks in advance.
-Steve



Quoting Steven Job :

> This exact same configuration works perfect on all RedHat distributions that
> we
> tested.
> When I only have a few domains it works perfectly (on Gentoo).
> Once you put a couple of thousand domains in the system it will no longer
> send
> any NOTIFY messages ("sending notifies"). It just takes the update and does
> nothing else. The secondary name servers will have to wait for the SOA to
> refresh.
>
> Here is the named.conf:
> acl "secdns" { 127.0.0.1/32; 192.168.1.0/24; };
>
> options {
> version "A great version";
> directory "/var/named";
> pid-file "/var/named/named.pid";
> // Server will attempt to do all work required to answer query.
> recursion no;
> allow-query { any; };
> allow-transfer { "secdns";};
> blackhole { none; };
> provide-ixfr yes;
> request-ixfr yes;
> tcp-clients 1000;
> transfers-per-ns 1000;
> transfers-out 2000;
> notify explicit;
> notify-source 192.168.1.100;
> also-notify { 192.168.1.11; 192.168.1.12; 192.168.1.13; 192.168.1.14;
> 192.168.1.15; 192.168.1.16; 192.168.1.17; 192.168.1.18; };
> };
> zone "." { type hint;
> file "named.root";
> };
> include "/etc/zones.conf";
>
>
> Is there anyway to make the logging more verbose to see what Bind is doing
> when
> it should be sending a notify? It gets the dynamic update and then it just
> sits there (no notify is sent).
> Has anyone had this problem before on Gentoo or other operating system?
> We have tried bind versions 9.2.x all the way to 9.3. All have the exact
> same
> results.
>
> Thanks for any help,
> -Steve
>
>
>