nsd users - Jan 2012 - zone addition to running daemon in NSD4

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 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).

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20120124/51c9787d/attachment.htm>

-----BEGIN PGP SIGNED MESSAGE-----
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:
pattern:
	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,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPH7wbAAoJEJ9vHC1+BF+NmOcP/1OgaUeHENoWCq//9FMfrMsW
egYZ1cLCal4HxyO3UxfNCdvqH26BTj8newKf6aeH/qF9wrc8wUPQJEN5Tef8WEcy
sXMffuyF1GGif8iNRVkqpVbi3IGGZ2SjtePQT1mrIVOw3mOAyv1r59GoVZUBXR4u
e2x9N+NYAhYiR6mc9Uesa0dZj0fqfHtcoiYYefmDUMCYOVMFB5Gdis4M4GcFIM9Z
tQFAhfTDk0Iqg9Xy9bs2LVptAhfoKNGO4mFjqptG0H1B8iV/GwRxLITsU/5XzUne
JARD2BmpTreTq7d9CYf43n8G9PZdH4S78MnBeOzXTE6HI1atuLnW78IqY1mNQWHn
U4mFaRKQ2Afiiupc6a5t1U4yHCT7MjtyUtO0uWd6QtPMpOBfIkDd0BXzIyZG2UUd
5m4acN9FvYaWKX3ZZl1Teeplc/OqdbcHClvz03qItcWzyNug6zDPkQFyhGPcvO6C
ywa0UjkegI/932m4fQZtdp1QfIG8e+qBqoU3a+WRNgdpqjC9gVTaREXFe1F1U4iU
pPBsXIlfE/VFiqOIOykmDjaB4SD6U1Yb3MOhKbZv0DVoyC6IllSSIeJNyjamIndj
8nGeSxaj/cqFy9Bw1RsywBuTArAKGIrCuXCVmTRsgYJloQ4uVuY87DRFGakCwNud
zAtfvppVcQ6nlpoubFpq
=DSHE
-----END PGP SIGNATURE-----