Hi Will,
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@edgecast.com <mailto:will@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