help with notify-source
tony z
I need the NOTIFY messages to go out on a specific IP, because I am using TSIG updates
to my slave and that slave will not accept a TCP NOTIFY connection from any other than one of
my specific IPs.
I put a notify-source directive inside my zone files and options area, but nothing seems to work.
BIND/named seems to randomly rotate through all my IPs sending NOTIFY, until it uses the IP
that my slave wants to hear from, and then the transfer from master to slave happens. But this takes like hours.
Does notify-source actually work, or am I using the wrong directive or using the right directive in the wrong manner.
thanks,
tony
Barry Margolin
> I have a BIND 9.x server with multiple ethernet interfaces and IPs.
What's the value of x?
> I need the NOTIFY messages to go out on a specific IP, because I am using
> TSIG updates
> to my slave and that slave will not accept a TCP NOTIFY connection from any
> other than one of
> my specific IPs.
> I put a notify-source directive inside my zone files and options area, but
> nothing seems to work.
> BIND/named seems to randomly rotate through all my IPs sending NOTIFY, until
> it uses the IP
> that my slave wants to hear from, and then the transfer from master to slave
> happens. But this takes like hours.
> Does notify-source actually work, or am I using the wrong directive or using
> the right directive in the wrong manner.
Post your named.conf.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
tony z
I have logs from my backup DNS which shows the slave DNS refusing notify's from my other IPs on the master DNS server... then eventually the right master IP sends the notify, and the AXFR proceeds and completes normally. Do you expect BIND to rotate it's NOTIFYs through various IPs on the multihomed server like this?
tony z
version of BIND is 9.3.3rc2
and the named.conf is:
// Default named.conf generated by install of bind-9.2.4-24.ELu
// changelog:
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;
};
include "/etc/rndc.key";
include "/var/named/keys/xxx.keys";
logging {
channel default_log {
file "/var/log/named/default.log" versions 7 size 1m;
severity debug 50;
print-category yes;
print-severity yes;
print-time yes;
};
channel query_log {
file "/var/log/named/query.log" versions 7 size 1m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
channel security_ch {
file "/var/log/named/named_sec.log" versions 7 size 1m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
channel dnssec_ch {
file "/var/log/named/dnssec.log" versions 7 size 1m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
channel log_zone_transfers {
file "/var/log/named/axfr.log" versions 7 size 1m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category default { default_log; };
category security { security_ch; };
category dnssec { dnssec_ch; };
category queries { query_log; };
category xfer-out { log_zone_transfers; };
};
// zone file for root servers, fres off internic.net
zone "." {
type hint;
file "named.ca";
};
// zone file for localhost
zone "localhost." in{
type master;
file "master.localhost";
allow-update { none; };
};
// zone file for revrerse lookup of localhost
zone "0.0.127.IN-ADDR.ARPA." {
type master;
file "localhost.rev";
allow-update { none; };
};
// zone file for xxx.us
zone "xxx.us" {
type master;
file "xxx.us";
allow-transfer { key 101436.163724.xxx; };
};
// zone file for xxx.com
zone "xxx.com" {
type master;
file "xxx.com";
allow-transfer { key 101436.163822.xxx; };
};
tony z
- took the IP that BIND seemed to really want to send NOTIFY's on (not the different/desired IP in 'notify-source')
- put that IP as the new master DNS IP in the slave definition for allowing transfers from
- added that IP as a second IP in my 'listen-on' so that BIND would listen on #53 connections from the slave starting the transfer
- as an added measure, that IP also went into my notify-source, even though I think (on my config) notify-source is not effective.
Voila. AXFRs happen fast and crisp. So notify-source doesn't seem to work to specify the IP used for NOTIFYs.
Mark Andrews
> I managed to hack around "notify-source" not working to my expectations. Sinc
> e BIND wanted to pick a different IP than I told it to via notify-source and
> listen-on (I wanted this to be the same IP for both purposes), I did the foll
> owing:
> - took the IP that BIND seemed to really want to send NOTIFY's on (not the di
> fferent/desired IP in 'notify-source')
> - put that IP as the new master DNS IP in the slave definition for allowing t
> ransfers from
> - added that IP as a second IP in my 'listen-on' so that BIND would listen on
> #53 connections from the slave starting the transfer
> - as an added measure, that IP also went into my notify-source, even though I
> think (on my config) notify-source is not effective.
> Voila. AXFRs happen fast and crisp. So notify-source doesn't seem to work to
> specify the IP used for NOTIFYs.
I suspect that you did not actually start or re-start named
with the configuration you said you did or you specfied a
address that the system was not configured with. These are
common operator errors.
There are NO proved cases of notify-source failing in 9
years of operation. notify-source is used everyday by
thousands of sites.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
tony z
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 for 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.
Barry Margolin
> 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 for
> 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?
tony z
yes I did check logs... I even turned on debug logging at level 50... no errors 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 checked now, and there is no other named.conf, no chroot directory, etc...
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?
Mark Andrews
> 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?
> 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.
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. Named uses bind(2) to ensure that responses
to queries also originate from the correct IP address.
If bind(2) is failing then responses to queries to the virtual
address would also fail.
Mark
tony z
>> 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?
Barry Margolin
> hi Barry,
> yes I did check logs... I even turned on debug logging at level 50... no
> errors 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 checked now, and there is no other named.conf, no chroot directory,
> etc...
And if you put a syntax error in the file, does it log an error?
Something MUST be causing it to ignore these lines in the file.
> 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?
If you used it wrong you would have gotten a syntax error in the log.
But it's behaving as if you didn't use it at all. Alias IPs are fine,
that's an expected use of this option.
Barry Margolin
Unless your IP really ends in "xxx", you edited it before posting.
tony z
I was reading the doc's wrong, and named would not start. Which also confirmed I was editing/using
the same named.conf that named was reading.
I really expected to see some sort of bind(2) error when I cranked up the logging debug level,
but I could not see anything unusual.
> Something MUST be causing it to ignore these lines in the file.
> If you used it wrong you would have gotten a syntax error in the log.
> But it's behaving as if you didn't use it at all. Alias IPs are fine,
> that's an expected use of this option.
Well this is why I came to this group, it seemed like my named.conf was correct.
I didn't see a problem in lower level networking causing bind(2) to fail to attach
to the notify-source IP address. Regarding the .XXX, yes, I just edited the actual
IP just to keep it anonymous.
ews_inc
Thanks for any help on this....
x = BIND 9.3.3rc2
the named.conf is:
// Default named.conf generated by install of bind-9.2.4-24.ELu
// changelog:
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;
};
include "/etc/rndc.key";
Barry Margolin
wrote:
> the named.conf is:
I doubt it. There are lots of "xxx" in what you posted, and I'll bet
any amount that the real named.conf file doesn't have them.
Since it's possible that your redacting is masking over the problem, I
don't think anyone is going to bother helping you until you give up all
the information hiding and post the real thing.
tony z
Now the AXFR's happen immediately, as one would expect.
From: Barry Margolin <bar...@alum.mit.edu>
To: comp-protoc...@isc.org
Sent: Sunday, March 30, 2008 6:53:46 PM
Subject: Re: help with notify-source