zone before delegation?
tmorizot at sd.is.irs.gov
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