Going crazy! -- "Sending Notifies" not working on Redhat Enterprise v3??

[Ronan Flood]

raiden at wonko.inow.com wrote:

> I have used Bind 9.2.1 with various flavors of Redhat for a while, and
> have had no problems.  However, I am having problems with zone
> transfers and the default installation of Bind 9.2.4rc6 in RHEL v3,
> and I believe that it has to do with notifies not occurring.  (When I
> say default installation, it is the installation that comes with RHEL
> Workstation, and is not "supported" by Redhat.)
> 
> I have two servers, one the master, the second the slave.  When the
> slave starts up, if none of the zones have been downloaded from the
> master, it successfully downloads them.  Both DNS servers seem to be
> fully operational.  That's the good part.
> 
> The bad part is, when I restart the master server, it says in the
> messages log that it is sending notifies, but none seem to be being
> sent.  (There are no errors in the logs.)  I have udp and tcp port 53
> open for all traffic on both servers, but I have also tried this with
> the firewalls disabled.
> 
> I have sniffed traffic on both machines, and I do not see any
> notification traffic at all (I believe it should be tcp traffic over
> port 53, but I don't see any traffic what-so-ever when it claims it's
> "sending notifies").

Notifies are sent over UDP.

> However, when the refresh timeout is reached, the slave server DOES
> poll the master server, and DOES succesfully download the new zone
> file.
> 
> Has anyone else experienced such a problem?
> 
> Below are my named.custom configuration files (that are read by
> named.conf as per RHEL's configuration file setup):
> 
> ## master -- 64.71.162.42
> options {
>         query-source address * port 53;
>         directory "/var/named";
>         pid-file "/var/run/named/named.pid";
>         allow-transfer { 64.71.162.46; };
> };
> 
> 
> logging {
>         category lame-servers { null; };
> };
> 
> zone "myvemma.com" IN {
>         type master;
>         file "db.myvemma.com";
> };
> 
> zone "subnet40.162.71.64.in-addr.arpa" {
>         type master;
>         file "db.64.71.162.40";
> };
> 
> zone "0.0.127.in-addr.arpa" IN {
>         type master;
>         file "db.127.0.0";
>         allow-update { none; };
> };
> 
> zone "." {
>         type hint;
>         file "db.cache";
> };
> 
> 
> ## slave -- 64.71.162.46
> options {
>         query-source address * port 53;
>         directory "/var/named";
>         pid-file "/var/run/named/named.pid";
> };
> 
> logging {
>         category lame-servers { null; };
> };
> 
> zone "myvemma.com" IN {
>         type slave;
>         file "slaves/bak.myvemma.com";
>         masters { 64.71.162.42; };
> };
> 
> zone "subnet40.162.71.64.in-addr.arpa"{
>         type slave;
>         file "slaves/bak.64.71.162.40";
>         masters { 64.71.162.42; };
> };
> 
> zone "0.0.127.in-addr.arpa" IN {
>         type master;
>         file "db.127.0.0";
>         allow-update { none; };
> };
> 
> zone "." {
>         type hint;
>         file "db.cache";
> };
> 
> ## zone file on master
> $TTL 3h
> myvemma.com. IN SOA ns1.myvemma.com. support.myvemma.com. (
>         2004101101       ; serial
>         3h      ; refresh after 3 hours
>         1h      ; retry after 1 hour
>         1w      ; expire after 1 week
>         1h )    ; negative caching TTL of 1 hour
> 
> myvemma.com.    IN NS   ns1.myvemma.com.
> myvemma.com.    IN NS   ns2.myvemma.com.

> web01.myvemma.com.              IN A    64.71.162.46
> web02.myvemma.com.              IN A    64.71.162.42

> ns1.myvemma.com.                IN CNAME        web01.myvemma.com.
> ns2.myvemma.com.                IN CNAME        web02.myvemma.com.

Possibly having your NS records as CNAMEs (which you should not have)
is not doing you any favours ...

Could you rewrite this as:

 ns1.myvemma.com.                IN A    64.71.162.46
 ns2.myvemma.com.                IN A    64.71.162.42

 web01.myvemma.com.              IN CNAME        ns1.myvemma.com.
 web02.myvemma.com.              IN CNAME        ns2.myvemma.com.

and see if that helps?  Are the NS records for zone
subnet40.162.71.64.in-addr.arpa also ns1/ns2.myvemma.com?

-- 
                      Ronan Flood <R.Flood at noc.ulcc.ac.uk>
                        working for but not speaking for
             Network Services, University of London Computer Centre
     (which means: don't bother ULCC if I've said something you don't like)