[nsd-users] reloading NSD zone configuration

[Ondřej Surý]

Howdy,

there are/was some movement in IETF for management protocol which
would allow adding new zones from master to primary without operator
help. And I would oppose adding this feature to NSD before some kind
of protocol is standardized.

But even that there are several options you could use to achieve what you need:

Option A)

Add second server and deploy H-A (VRRP/UCARP/Heartbeat/whatever) to
switch primary IP address between servers in cluster. Do a reload on
passive server then switch nodes.

Option B)

Same, but with only one server. Make one NSD listen on port 1053,
second NSD listen on port 2053. Both serve data from same database.
Use your firewall rules to redirect port 53 udp+tcp to active server.
When adding new zone - apply same logic as in Option A - reload
inactive daemon, switch to it using iptables, reload second daemon.

Option C)

Just add one more DNS server and reload one at time. DNS resolvers can
cope with that just fine (even with just two, but three are better if
one goes down for some other reason).

Option D)

Maybe you don't have a right tool for what you are doing. It's no use
to forced usage of NSD if another tool/daemon would serve you better.

Ondrej

2009/4/29 Mohammad H. Al-Shami <mshami at tagorg.com>:
> Hi guys,
>
> I've been interested in this issue for a while now, and I hope NSD has that soon. But for the time being I propose a workaround.
>
> I'm not a big fan of zone transfers, hated them since the day I set up my first DNS server. Currently I use a patched version of VegaDNS with a backend Perl script to manage my zones. The Perl script generates the configration and zone files then copies them to all my servers.
>
> As for adding/removing a zone, at the end of the Perl script:
> 1) Shut down server A
> 2) Wait 5 seconds
> 3) Start server A
> 4) Wait 5 seconds
> 5) Shut down server B
> ...
>
> With this you have only one of your servers restarting at a certain moment.
>
> When I wrote the script just restarting NSD caused it to generate an error, if I remember correctly it couldn't bind to port 53. This happened only the first time NSD was restarted after a server reboot, which was weird. Since the script worked properly as it is I haven't bothered in checking it again.
>
> Hope that helps.
>
> Regards,
> Mohammad H. Al-Shami
>
> On Tuesday 28 April 2009 12:36:29 Antti Ristimäki wrote:
>> On Tue, 28 Apr 2009, Jelte Jansen wrote:
>> > If you restart NSD, with some new slave zones added, it will serve existing
>> > zones as soon as it is up (i.e. within seconds on most systems, see below for my
>> > private setup and some very anecdotal timing benchmarks). It will also start to
>> > transfer the new slave zones, but while it is doing that it already serves
>> > existing ones.
>>
>> Thank you for this very valuable information. Restart times of this
>> magnitude would be acceptable for us, given that the frequency of zone
>> additions is rather low in our environment.
>>
>> > Throwing queries against it
>> > from the other side i would estimate that 1 or 2 seconds of those are spent
>> > waiting for the previous process to stop, at which point it is still serving.
>>
>> Regarding the process stopping phase, what would be expected to happen in
>> case that one or more zone transfers are pending at the same time when
>> SIGTERM is sent to the previous process?
>>
>> BR,
>>
>> Antti
>> _______________________________________________
>> nsd-users mailing list
>> nsd-users at NLnetLabs.nl
>> http://open.nlnetlabs.nl/mailman/listinfo/nsd-users
>>
>
> _______________________________________________
> nsd-users mailing list
> nsd-users at NLnetLabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/nsd-users
>



-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/