[nsd-users] zone addition to running daemon in NSD4

W.C.A. Wijngaards wouter at nlnetlabs.nl
Wed Jan 25 08:23:55 UTC 2012

Hash: SHA1

Hi Will,

On 01/24/2012 10:01 PM, Will Pressly wrote:
> Hi All,
> I am experimenting with NSD4, and am having a little trouble
> understanding the workflow for adding a zone to the running daemon with
> the "nsd-control addzone <zone name <http://zone.name>> <pattern>"
> functionality. Specifically, I am interested in a solution that does not
> involve zone transfers. From the man page:
>        addzone <zone name> <pattern name>
>               Add a new zone to the running server.  The zone is added
> to the zonelist file on disk, so it stays after  a  restart.
>               The  pattern name determines the options for the new zone.
>  For slave zones a zone transfer is immediately attempted.
>               For zones with a zonefile, the zone file is attempted to
> be read in.
> from this information, how do you specify the zonefile for the new,
> added zone using a pattern? I tried creating a pattern with the zonefile

You can specify in the pattern, the zonename with special markup:
	name: "blabla"
	zonefile: "master/%s.zone"
	# %s is replaced with the zone name

This puts the zonefiles in the "master" directory, and they are called
"example.com.zone".  There are more %x markups if you want different
names, like, folder/e/x/example.com, or /data/uk/co/example.co.uk.

This means if you add a zone with this pattern blabla, then it attempts
to read that file (right away, from disk), and attempts to serve it.

I think $ORIGIN is set to the zone name, and '@' can be used for the
zone name itself, in the zonefile.  So you can write 'standard zone
files' that are fairly zonename independent.

> option set to the path of the new, added zone -- then invoked the
> command with the specified zone and pattern. The problem is that it
> looks as if the running daemon cannot be made aware of new patterns
> specified in the nsd.conf without a restart of the daemon (as the
> nsd-control add zone would work if the daemon was started with the
> pattern in the nsd.conf, otherwise not).

So with the pattern above, I would think you would be able to add a
number of zones with one pattern.  The assumption behind the design is
that ten or a hundred patterns are enough for thousands of zones.  There
is no limit on the number of patterns and zones, though.

You can also reread the patterns, with nsd-control repattern.  The
repattern command is not as efficient as addzone.

After you repattern, you can use your newly added nsd.conf pattern and
addzone with it.

> Am I missing something here? Does anyone have any input on how this
> workflow should happen without zone transfers? I think I just haven't
> fully connected the dots on this.
> Thanks,
> Will Pressly, Ph.D.
> EdgeCast Networks
> will at edgecast.com <mailto:will at edgecast.com>

If you also set notify: and provide-xfr: statements it'll send NOTIFY to
those slave servers after it reads the zonefile you provided from disk.

Note that NSD4 implementation has not finished.  The features discussed
here are implemented and available for tests.

Best regards,
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/


More information about the nsd-users mailing list