-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Teran,
Thanks for the feedback. I have put my comments inline.
Teran McKinney wrote:> Hi,
>
> I have been using NSD for about a month and a half and have been quite
> pleased with it. From my use, I have found a couple things I would
> like to suggest. I run three NSD instances, all coexisting with
> Unbound for recursive resolving on seperate servers. I noticed two
> awkward situations that can arise when running multiple DNS servers on
> the same server. One is that `nsdc patch`, only tells localhost to
> patch. In my cases, the caching resolver would listen on ::1
> (especially in the case of VPS), and NSD would sit on my IPv4 address
> and an external IPv6 address.
nsdc is the control script of NSD. It is intended to be used at the
localhost. 'nsdc patch' for example, reads the configuration file and
merges back zone transfers (if any) to the zone files. nsdc does not
provide ways to remote control the nameserver.
> When `nsdc notify` is called, it sends a
> request to ::1, which isn't too useful as the recursive resolver
> catches it instead. Perhaps nsdc could read nsd.conf, and/or have an
> option to send the request to a different IP? Can notifications be
> done with `drill`?
Are you running a NSD slave at the same server as the NSD master? Only
in that case, it is useful to send a notify request to the localhost.
How 'nsdc notify' works, is that it sends notify request to all slaves
for zones that have the notify keyword in the configuration file. So, if
you are running a master zone for example.net. and you want to notify
your slaves at 1.2.3.4 and 1.2.3.5, your configuration should look like:
zone:
name: "example.net"
zonefile: "example.net.zone"
# slave 1
notify: 1.2.3.4 NOKEY
provide-xfr: 1.2.3.4 NOKEY
# slave 2
notify: 1.2.3.4 NOKEY
provide-xfr: 1.2.3.4 NOKEY
Only if you have
notify: ::1 SOMEKEY
in you configuration, nsdc notify will try to send a notify request to
::1. If you didn't have that line in your configuration file and it did
send a notify request to ::1, it sounds like that might be a bug.
Hopefully, this will provide more clarity about the NSD control script
and how it's use is intended.
> The other suggestion I have for NSD is an outgoing-interfaces option,
> like in Unbound. If you add aditional IP addresses to the server, you
> cannot configure which IP requests go out of for AXFR requests. The
> slave servers would probably be configured to only allow notifications
> for zone transfer requests from the master server's address, but as
> soon as the master server adds another address and it becomes a
> prefered route, the notifications are denied as they go out of the
> foriegn IP.
This is a known feature request: see
http://www.nlnetlabs.nl/bugs/show_bug.cgi?id=148
Unfortunately, it was not picked up for a long time. I have assigned
this 'bug' to me, and I expect it to be in the NSD 3.2 release.
> NSD is an awesome authoritive server, thank you all for the time and
> effort spent on it. I hope that these suggestions are useful. Of
> course, these can be worked around, but I think that a couple extra
> features in this regard could make things easier and more ideal.
And thank you for your feedback!
Matthijs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIxj5bIXqNzxRs6egRAgh8AJ9hOSUvek3Xkk4xkaeOIhjRa6MgHwCeIgh+
qZ7HraEir+7QWrSImaxXDHI=nHyI
-----END PGP SIGNATURE-----