Re: help with notify-source - DNS

This is a discussion on Re: help with notify-source - DNS ; >> 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: help with notify-source

  1. Re: help with notify-source

    >> 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@alum.mit.edu
    > Arlington, MA
    > *** PLEASE don't copy me on replies, I'll read them in the group ***
    >
    >
    >
    >
    >
    >
    >






  2. Re: help with notify-source

    In article , tony z 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@alum.mit.edu
    > > Arlington, MA
    > > *** PLEASE don't copy me on replies, I'll read them in the group ***
    > >
    > >
    > >
    > >
    > >
    > >
    > >


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


+ Reply to Thread