Re: zone before delegation?
On Fri, Oct 28, 2011 at 05:39:05PM +, 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.
Actually, the opposite - sorry if I was unclear. Maybe an example will help. . .
If we start with this config:
zone example.com {
type master;
file /usr/local/etc/bind/example.com.zone;
};
# example.com.zone
$TTL 86400
@ IN SOA ns.example.com hostmaster.example.com (
2011102900 86400 14400 864000 86400 )
IN NS ns.example.com.
;
www IN A 192.0.2.1
We can add a subdomain of example.com simply by creating the zone file and
adding an entry in named.conf, *without* placing anything in the example.com
zone itself:
zone test.example.com {
type master;
file /usr/local/etc/bind/test.example.com.zome;
};
# test.example.com.zone
$TTL 86400
@ IN SOA ns.example.com hostmaster.example.com (
2011102900 86400 14400 864000 86400 )
IN NS ns.example.com.
;
testserver IN A 198.51.100.20
There is no connection between example.com and test.example.com, since the
records for test are in a separate zone and there's no delegation point (no NS
records for 'test.example.com'). However, any queries for test.example.com have
to work through example.com first, and the same server knows about both zones.
When someone asks for 'testserver.test.example.com' at ns.example.com, it will
provide an authoritative answer for the A record and include an NS record in
the additional section. Everything will work just fine; that's true even if
there are additional authoritative servers, as long as all of the servers for
example.com are also authoritative for test.example.com.
That said, here's the right way to do it; after creating the subdomain zone
file and adding the entry in named.conf, go back to the parent:
# example.com.zone
$TTL 86400
@ IN SOA ns.example.com hostmaster.example.com (
2011102901 86400 14400 864000 86400 )
IN NS ns.example.com.
;
www IN A 192.0.2.1
;
testIN NS ns.example.com.
Now everything's consistent and complete. That configuration will always work,
regardless of the location of the authoritative nameserver(s) for
test.example.com. It will also work when you sign test.example.com and add DS
records in example.com to secure it.
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.
That's fine, but still create the NS records. You can keep them at a low TTL
until your transition, if you want to speed up the process when you do make the
change.
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.
:-)
Actually I think they're very different. Both will require some effort and some
pain; IPv6 more of both and for less obvious return (though it truly does have
some significant advantages). DNSSEC - once it is sufficiently deployed - will
make some very cool things possible, well beyond the basic, but very important
addition of end-to-end DNS integrity. Have a look at the freshly minted RFC
6394 for one early example. . .
Bill.
___
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
RE: zone before delegation?
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
