Hi
I'm running the nsd version in Debian stable (2.2.1). The machine has four IPs
bound to eth0, eth0:0, eth0:1 and eth0:2.
nsd is bound to the second IP via the "-a" command line switch.
But I couldn't find a switch for nsd-notify, so it is sending its notify to the
secondary from the fourth IP address.
Can I change that behaviour somehow?
TIA
Thomas
Thomas Huehn wrote:
Hi
I'm running the nsd version in Debian stable (2.2.1). The machine has four IPs
bound to eth0, eth0:0, eth0:1 and eth0:2.nsd is bound to the second IP via the "-a" command line switch.
But I couldn't find a switch for nsd-notify, so it is sending its notify to the
secondary from the fourth IP address.Can I change that behaviour somehow?
No this feature does not exist.
Please note that when you update the zone on the master - by providing
an updated zone file to the master, then nsd itself will detect the
change and send notifies to the secondary. However, to preempt your
question, that notify send also uses the default from address that the
system provides.
NSD tries to avoid creeping featurism. So I am hesitant about new
features such as this one.
Best regards,
Wouter
It is essential on any multihomed nameserver. If you don't want to add
more "features" in the config file, then at the very least, use the
IP specified with "-a" for everything, becaues that's really want people
want.
A very typical setup is to have machines with a "core" IP address, and
then to have all services on the box on their own IP address, so that
you can move services to another box without having to renumber
the base IP of any of your boxes. It also allows for having multiple
services on a box (eg dns and smtp) with their own ip, so you can
still independantly move them to other boxes later on.
So, IMHO, not feature creep, but basic functionality.
Paul
: -----BEGIN PGP SIGNED MESSAGE-----
: Hash: SHA1
:
: Thomas Huehn wrote:
: > Hi
: >
: > I'm running the nsd version in Debian stable (2.2.1). The machine
: > has four IPs bound to eth0, eth0:0, eth0:1 and eth0:2.
: >
: > nsd is bound to the second IP via the "-a" command line switch.
: >
: > But I couldn't find a switch for nsd-notify, so it is sending its
: > notify to the secondary from the fourth IP address.
: >
: > Can I change that behaviour somehow?
:
: No this feature does not exist.
:
: Please note that when you update the zone on the master - by providing
: an updated zone file to the master, then nsd itself will detect the
: change and send notifies to the secondary. However, to preempt your
: question, that notify send also uses the default from address that the
: system provides.
:
: NSD tries to avoid creeping featurism. So I am hesitant about new
: features such as this one.
Some secondaries are configured only to allow AXFRs from a specific
address, which Murphy says will be not the default. I think that while
it is creeping featurism, its something that has to be done.
'src: 127.0.0.1', in the zone definition sounds not terribly dumb. 
Paul Wouters wrote:
Please note that when you update the zone on the master - by providing
an updated zone file to the master, then nsd itself will detect the
change and send notifies to the secondary. However, to preempt your
question, that notify send also uses the default from address that the
system provides.NSD tries to avoid creeping featurism. So I am hesitant about new
features such as this one.It is essential on any multihomed nameserver. If you don't want to add
more "features" in the config file, then at the very least, use the
IP specified with "-a" for everything, becaues that's really want people
want.
ACK.
As it looks now I will remove nsd and install something else because the
secondary (which I have no administrative control over) doesn't
synchronize (and a quite important zone update must happen).
A very typical setup is to have machines with a "core" IP address, and
then to have all services on the box on their own IP address, so that
you can move services to another box without having to renumber
the base IP of any of your boxes. It also allows for having multiple
services on a box (eg dns and smtp) with their own ip, so you can
still independantly move them to other boxes later on.
I am grouping several services depending on who is allowed to access them.
So, IMHO, not feature creep, but basic functionality.
At least as soon as you allow binding nsd to an IP address (via -a)
which is sensible in any case. Sometimes it's not easy to control which
IP is deemed "default" by the system.
Thomas
Thomas Hühn wrote:
So, IMHO, not feature creep, but basic functionality.
At least as soon as you allow binding nsd to an IP address (via -a)
which is sensible in any case. Sometimes it's not easy to control which
IP is deemed "default" by the system.
Hi,
I see this feature is much wanted. I'll put it on the TODO list, and
will get around to it for a later release. Right now I am considering
some sort of 'src: <ipaddress [@port]>' that you can put in a zone. This
would make zone transfers and notifies for that zone (sent by nsd
process) come from that interface.
People also asked for nsd-xfer and nsd-notify to be changed, with
similar -a flags to bind an interface. But these are marked deprecated
as the functionality moved to the secondary process inside the server.
So the nsd-xfer and nsd-notify tools are marked obsolete and will be
removed from the package in some later release.
I will not be able to do this right away as I am investigating a more
pressing bug (bugzilla #147). The zone transfer system was designed to
handle memory in a way that now turns out to be very impractical. It
leaks memory about the size of the combined sizes of all zone transfers
(incoming). The memory is not really leaked, it is released when nsd
reads a new database file (nsdc patch). The design is simple and safe,
but in reality some people run into operational problems. You can tell
you suffer from this problem if the log entries 'memory churn .. bytes
wasted' show large values. Fixing this is my priority.
Best regards,
Wouter
Wouter Wijngaards wrote:
At least as soon as you allow binding nsd to an IP address (via -a)
which is sensible in any case. Sometimes it's not easy to control which
IP is deemed "default" by the system.Hi,
I see this feature is much wanted. I'll put it on the TODO list, and
will get around to it for a later release. Right now I am considering
Thanks.
wasted' show large values. Fixing this is my priority.
Of course, I understand that.
Thomas
Then adjust your SOA refresh/retry timers appropriately. Or send the
notify yourself using something like `dnsnotify'.
ATB,
james
Wouter Wijngaards wrote:
I see this feature is much wanted. I'll put it on the TODO list, and
will get around to it for a later release. Right now I am considering
some sort of 'src: <ipaddress [@port]>' that you can put in a zone. This
would make zone transfers and notifies for that zone (sent by nsd
process) come from that interface.People also asked for nsd-xfer and nsd-notify to be changed, with
similar -a flags to bind an interface. But these are marked deprecated
as the functionality moved to the secondary process inside the server.
So the nsd-xfer and nsd-notify tools are marked obsolete and will be
removed from the package in some later release.I will not be able to do this right away as I am investigating a more
pressing bug (bugzilla #147). The zone transfer system was designed to
handle memory in a way that now turns out to be very impractical. It
leaks memory about the size of the combined sizes of all zone transfers
(incoming). The memory is not really leaked, it is released when nsd
reads a new database file (nsdc patch). The design is simple and safe,
but in reality some people run into operational problems. You can tell
you suffer from this problem if the log entries 'memory churn .. bytes
wasted' show large values. Fixing this is my priority.
Any news on this? I recently found out I also really need this feature.
Currently all notifies originate from the wrong (default) interface 
Cheers,
-Wim -/- SURFnet
Wim Biemolt wrote:
Any news on this? I recently found out I also really need this feature.
Currently all notifies originate from the wrong (default) interface
The next release is expected to be a bugfix release. Then I'll get to
this feature, followed by notify-from-NS-set features (see other thread).
Best regards,
Wouter