Nsupdate usage scenario
rob0 at gmx.co.uk
Wed May 4 20:27:22 UTC 2016
On Wed, May 04, 2016 at 03:17:38PM -0400, Paul Kosinski wrote:
> Interesting idea -- it never occurred to me that I could have
> separate zone files for sub-domains.
Every zone is a subzone of its parent zone.
> So, if I had a tiny zone file for "dynamic.example.com" alone, and
> a bigger zone file for all the other stuff for "example.com", could
> I be *sure* that nsupdate would *only* modify the tiny file, and
> not mess with the bigger, main file?
> Or would I also have to put a ZONE statement as the first line of
> the nsupdate data stream specifying "dynamic.example.com" as the
> zone to be updated? (And would that *guarantee* the main file was
> not changed?)
This is a bigger can of worms than you think. I did it with my own
dynamic zone some years back, now wishing to flatten it back into
the parent zone (because they are both dynamic now.)
* You have to delegate the [sub]zone to a set of nameservers
* You have to configure those nameservers to serve that [sub]zone
The NS for your subzone can be, but need not be, the same as the ones
serving your parent zone. Choose one to be master. Put that name in
the SOA MNAME field for the subzone. (The MNAME is used by nsupdate
in choosing where to send an update. It's not essential because you
can also use a "server" line in your nsupdate input.)
Note that on the master you need an allow-update or update-policy in
your zone statement.
My personal recommendation: get over the idea of looking at zone
files; use "dig axfr example.com. | less". Let named manage and
serve the DNS data as it will. Comments can be included as TXT
records if you like.
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
More information about the bind-users