zone before delegation?

Scott Morizot tmorizot at
Sat Oct 29 14:14:17 UTC 2011

On 28 Oct 2011 at 17:39, Laws, Peter C. wrote:
> OK, so simply putting the NS records in the parent zone is
> sufficient to make it a separate zone.  No need to put stuff in
> named.conf unless I want to or until I actually delegate to a
> different set of nameservers. 

If you put NS records delegating a subdomain in the parent zone file, 
that creates a zone cut and you can no longer have any records in the 
parent about the child zone except glue records (if one or more of the 
nameservers for the child zone lie below the zone cut) and DS records 
(which are owned and signed by the parent zone and are the one record 
type that don't follow the zone cut rule).

> My thought was to create the new zones as zones on the parent server
> as a prelude to actually delegating them, in a  sense, delegating
> the zone to myself.  That will let me clean stuff up and get it
> ready for the coming move.  

Not sure I understand what you're trying to do, but this is the most 
correct order for establishing a new delegated zone (or moving a zone 
from one nameserver to another). First configure the zone as a master 
zone on the nameservers on which it will run. (Create the zone files and 
the configuration in named.conf on the new nameservers for the zone, 
whether or not they are the same nameservers as the parent.) Make sure 
those nameservers can respond authoritatively for the zone. Then add or 
change the NS records in the parent zone.

The first step configures the nameservers so they can respond 
authoritatively for the zone. The second step tells the rest of the world 
to query those nameservers for the zone. If you're creating a new zone 
cut and you're putting the new child zones on the same nameservers as the 
parent zone, then you can do both steps at once. On the master 
nameserver, move all the child records to the new zonefiles, add the NS 
records to the parent zone, change the named.conf configuration and 
restart named. And update the named.conf with the new child slave 
configuration on the other nameservers.

> Yes, DNSSEC is, IMHO, much like IPv6 - no one wants to mess with it
> but a lot of people claim it's inevitable.  *Hopefully* both will
> end up like maglevs and monorails - "technology of the future:
> always has been, always will be".  :-) 

Hopefully? So you actually want people to be able to spoof your 
authoritative DNS records almost at will? That's a curious perspective.

And while IPv6 transition is, at this point, not certain, what is certain 
is that we're effectively out of IPv4 addresses. APNIC has been out for a 
while. RIPE runs out in the next few months. It's uncertain at this point 
when ARIN will run out, but ARIN, AfriNIC and LACNIC will all run out 
sometime in the next couple of years. The only alternative to IPv6 is to 
return to a world of separate proprietary enclaves rather than a single, 
global inter-connected set of networks running the same protocol. It's a 
world of rationing where everyone can only run and access what their 
provider allows and supports. It's an ugly world and nothing at all like 
the Internet we've enjoyed for the past couple of decades. I'm old enough 
to remember what things were like when networks were all proprietary 
enclaves and I'm not eager to return to that model personally. It's 
doubtful that all the CGN solutions will really be the same and likely 
only certain protocols/ports will be supported -- throttling the 
development of new technologies. And it creates a scarcity model which 
will likely push prices for using the service up. With that world as the 
only likely alternative, I certainly hope IPv6 transition succeeds.


More information about the bind-users mailing list