Awesome! Thanks, Wouter! That is EXACTLY what I was looking for.<div><br></div><div>Thanks,</div><div>Will<br><div><div><br><div class="gmail_quote">On Wed, Jan 25, 2012 at 12:23 AM, W.C.A. Wijngaards <span dir="ltr"><<a href="mailto:wouter@nlnetlabs.nl">wouter@nlnetlabs.nl</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi Will,<br>
<div class="im"><br>
On 01/24/2012 10:01 PM, Will Pressly wrote:<br>
> Hi All,<br>
><br>
> I am experimenting with NSD4, and am having a little trouble<br>
> understanding the workflow for adding a zone to the running daemon with<br>
</div>> the "nsd-control addzone <zone name <<a href="http://zone.name" target="_blank">http://zone.name</a>>> <pattern>"<br>
<div class="im">> functionality. Specifically, I am interested in a solution that does not<br>
> involve zone transfers. From the man page:<br>
><br>
>        addzone <zone name> <pattern name><br>
>               Add a new zone to the running server.  The zone is added<br>
> to the zonelist file on disk, so it stays after  a  restart.<br>
>               The  pattern name determines the options for the new zone.<br>
>  For slave zones a zone transfer is immediately attempted.<br>
>               For zones with a zonefile, the zone file is attempted to<br>
> be read in.<br>
><br>
> from this information, how do you specify the zonefile for the new,<br>
> added zone using a pattern? I tried creating a pattern with the zonefile<br>
<br>
</div>You can specify in the pattern, the zonename with special markup:<br>
pattern:<br>
        name: "blabla"<br>
        ...<br>
        zonefile: "master/%s.zone"<br>
        # %s is replaced with the zone name<br>
<br>
This puts the zonefiles in the "master" directory, and they are called<br>
"example.com.zone".  There are more %x markups if you want different<br>
names, like, folder/e/x/<a href="http://example.com" target="_blank">example.com</a>, or /data/uk/co/<a href="http://example.co.uk" target="_blank">example.co.uk</a>.<br>
<br>
This means if you add a zone with this pattern blabla, then it attempts<br>
to read that file (right away, from disk), and attempts to serve it.<br>
<br>
I think $ORIGIN is set to the zone name, and '@' can be used for the<br>
zone name itself, in the zonefile.  So you can write 'standard zone<br>
files' that are fairly zonename independent.<br>
<div class="im"><br>
> option set to the path of the new, added zone -- then invoked the<br>
> command with the specified zone and pattern. The problem is that it<br>
> looks as if the running daemon cannot be made aware of new patterns<br>
> specified in the nsd.conf without a restart of the daemon (as the<br>
> nsd-control add zone would work if the daemon was started with the<br>
> pattern in the nsd.conf, otherwise not).<br>
<br>
</div>So with the pattern above, I would think you would be able to add a<br>
number of zones with one pattern.  The assumption behind the design is<br>
that ten or a hundred patterns are enough for thousands of zones.  There<br>
is no limit on the number of patterns and zones, though.<br>
<br>
You can also reread the patterns, with nsd-control repattern.  The<br>
repattern command is not as efficient as addzone.<br>
<br>
After you repattern, you can use your newly added nsd.conf pattern and<br>
addzone with it.<br>
<div class="im"><br>
> Am I missing something here? Does anyone have any input on how this<br>
> workflow should happen without zone transfers? I think I just haven't<br>
> fully connected the dots on this.<br>
><br>
> Thanks,<br>
> Will Pressly, Ph.D.<br>
> EdgeCast Networks<br>
</div>> <a href="mailto:will@edgecast.com">will@edgecast.com</a> <mailto:<a href="mailto:will@edgecast.com">will@edgecast.com</a>><br>
<br>
If you also set notify: and provide-xfr: statements it'll send NOTIFY to<br>
those slave servers after it reads the zonefile you provided from disk.<br>
<br>
Note that NSD4 implementation has not finished.  The features discussed<br>
here are implemented and available for tests.<br>
<br>
Best regards,<br>
   Wouter<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.15 (GNU/Linux)<br>
Comment: Using GnuPG with SUSE - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
iQIcBAEBAgAGBQJPH7wbAAoJEJ9vHC1+BF+NmOcP/1OgaUeHENoWCq//9FMfrMsW<br>
egYZ1cLCal4HxyO3UxfNCdvqH26BTj8newKf6aeH/qF9wrc8wUPQJEN5Tef8WEcy<br>
sXMffuyF1GGif8iNRVkqpVbi3IGGZ2SjtePQT1mrIVOw3mOAyv1r59GoVZUBXR4u<br>
e2x9N+NYAhYiR6mc9Uesa0dZj0fqfHtcoiYYefmDUMCYOVMFB5Gdis4M4GcFIM9Z<br>
tQFAhfTDk0Iqg9Xy9bs2LVptAhfoKNGO4mFjqptG0H1B8iV/GwRxLITsU/5XzUne<br>
JARD2BmpTreTq7d9CYf43n8G9PZdH4S78MnBeOzXTE6HI1atuLnW78IqY1mNQWHn<br>
U4mFaRKQ2Afiiupc6a5t1U4yHCT7MjtyUtO0uWd6QtPMpOBfIkDd0BXzIyZG2UUd<br>
5m4acN9FvYaWKX3ZZl1Teeplc/OqdbcHClvz03qItcWzyNug6zDPkQFyhGPcvO6C<br>
ywa0UjkegI/932m4fQZtdp1QfIG8e+qBqoU3a+WRNgdpqjC9gVTaREXFe1F1U4iU<br>
pPBsXIlfE/VFiqOIOykmDjaB4SD6U1Yb3MOhKbZv0DVoyC6IllSSIeJNyjamIndj<br>
8nGeSxaj/cqFy9Bw1RsywBuTArAKGIrCuXCVmTRsgYJloQ4uVuY87DRFGakCwNud<br>
zAtfvppVcQ6nlpoubFpq<br>
=DSHE<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div></div></div>