zone before delegation?

[Bill Owens]

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.