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>
W.C.A. Wijngaards
2012-Jan-25 08:23 UTC
[nsd-users] zone addition to running daemon in NSD4
-----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 zonefileYou 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-----