On Fri, Oct 28, 2011 at 05:39:05PM +0000, 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
;
test IN 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
