Suggestions for NSD

NSD
1

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. 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`?

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.

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.

Let me know if anything needs to be clarified or if you have any questions.

Thanks,
Teran (sega01)

2

Hi Teran,

This has been requested before, but sadly hasn't gotten any attention since.

My organisation would benefit alot from this option, so I'm quite glad others would like that option too.

Regards,

Kai Storbeck
XS4ALL Internet

3

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

4

Thank you for the quick reply.

As I was writing this reply I noticed that I was referencing to the
wrong command. `nsdc update` is what I meant instead of `nsdc notify`,
sorry for the confusion. I think that this should make more sense now
:-).

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.

I only have one NSD instance per machine. Two of my NSD servers also
host slave zones. In my setup, NSD originally only listens on public
IPv4 and IPv6 addresses. I originally had a recursive resolver
listening on ::1, but since `nsdc update` only sends notifications to
localhost, it was just going to my resolver instead of NSD. To solve
this, I moved Unbound to a seperate public IPv6 address and gave ::1
to NSD.

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.

Awesome, thank you.

Thanks,
Teran (sega01)