help with notify-source

[Barry Margolin]

In article <fscck4$2e89$1 at sf1.isc.org>, tony z <tzucc at yahoo.com> wrote:

> >> 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:

Unless your IP really ends in "xxx", you edited it before posting.

> 
> 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 ***
> >
> >
> >
> >
> >
> >
> >

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***