[nsd-users] Suggestions for NSD

Teran McKinney sega01 at gmail.com
Tue Sep 9 11:58:12 UTC 2008

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.

Teran (sega01)

More information about the nsd-users mailing list