help with notify-source

[tony z]

>> hi Barry,
>> yes I did check logs... I even turned on debug logging at level 50... no erro
>> rs on startup... no errors at times when NOTIFYs were going out on the wrong
>> IP address (in other words not the IP configured in notify-source). And yes,
>> I am 100% sure I was editing the named.conf that named was using... I just ch
>> ecked now, and there is no other named.conf, no chroot directory, etc...
> How do you know they were going out on the wrong address?

I recv'd the logs from my secondary DNS provider... and after my named restart he would see NOTIFY's coming
from all my various IPs... starting with 3 or 4 NOTIFY's from the same IP on eth1.
note: as per previous posts, on eth0 I have several aliases, each with a static IP assigned.

>> Again, perhaps the issue with BIND and IP's assigned to ethernet alias. BIND
>> kept going to eth1 first, then rotating around all my other IPs on the eth0:[
>> 0-3] .... totally ignoring my notify-source. I did post my named.conf... was
>> how I used notify-source ok?

> No you posted a modified version of named.conf which changed
> the IP addresses in question.

I did specify a notify-source... I repeat (in *'s) from the previous post:

options {
hostname "somehost";
version "ver9";
blackhole { 213.171.223.128; };
listen-on { 67.228.17.xxx; }; // virtual ETH for DNS
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
***** notify-source 67.228.17.xxx ; ******
allow-recursion { 127.0.0.1; 67.228.17.xxx; };
dnssec-enable yes;
};

>
> If you fail to specify a notify source most kernels use the
> first address on the interface unless the destination address
> causes the kernel to choose a different address usually
> because the destination address and a virtual address are
> on the same network.
>
> All notify-source does is cause named to bind(2) the socket
> to the specified address. If that fails to get the right
> address on the outgoing packet then you have a kernel bug
> in the IP stack. 

well it's RHEL5.

>Named uses bind(2) to ensure that responses
> to queries also originate from the correct IP address.
>

This is what I expected to have happen, but it seems it was not happening.
Please note, I was asking NOTIFY's and transfers to go out on the same IP that was being used for incoming
queries... is/was this my problem? Queries were coming on port 53, and NOTIFYs were going out
on some other port (higher than 1024, albeit on the wrong IP address), so I thought that bind(2)
should not fail because we were talking two different ports.

> If bind(2) is failing then responses to queries to the virtual
> address would also fail.

If bind(2) was failing, wouldn't I see that in any of the named logs?

> Mark

> > hi Mark,
> > Oh I did restart named for sure - several times. Not just reload, but
> > restart. And I definitely used addresses
> > copied from ifconfig, so that wasn't the issue either (just to make sure I
> > didn't typo).
> > named-checkconf reported no errors. I also scoured iptables for some
> > blocking condition
> > that could cause BIND to mess up. Nothing appeared out of order.
> >
> > The only thing I can think of, if it is a BIND bug, is that the IP I used f
> or
> > notify-source was
> > an IP assigned to an ethernet alias (RHEL5).
> >
> > In any case, I wouldn't bet that there isn't some other misconfiguration of
> 
> > mine that is causing this
> > but it sure isn't obvious.
>
> Are you absolutely sure that the config file you were editing is the one
> that named is using? There have been many occasions when someone has
> edited /etc/named.conf, but their system was actually using
> /etc/named/named.conf, or something like that.
>
> Have you checked your log to see if it's reporting any errors when it
> starts up?
>
> --
> Barry Margolin, barmar at alum.mit.edu
> Arlington, MA
> *** PLEASE don't copy me on replies, I'll read them in the group ***
>
>
>
>
>
>
>