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. Scott _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
