Nsupdate usage scenario

/dev/rob0 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 mailing list