Re: zone before delegation?
On Fri, Oct 28, 2011 at 04:48:10PM +, Laws, Peter C. wrote: > It seems like there are two ways I could delegate a zone. > > I could, in the zone file for the parent, simply list the name of the zone > and a number of NS records to which the zone has been delegated. > > Or, I could create a zone statement within named.conf that points to a file > that contains an SOA and a number of NS records to which the zone has been > delegated. > > Which is better and which should I prefer? If I'm reading this correctly, both ;) I take it the same servers are authoritative for both parent and child, right? You can get away with just creating the new zone in named.conf and not delegating it properly in the parent, due to a quirk in BIND behavior; it always answers from its authority and the chain of resolution will always pass through the server (because it's authoritative for the parent). But when* you configure DNSSEC, the lack of NS records in the parent zone will break your configuration. So installing them now will save you that grief later. I don't think that the order is particularly important, since queries can't be answered until the zone is created and configured in named.conf, though I suppose that creating the zone first is slightly more correct. Bill. (* note that I didn't say if you install DNSSEC, since I believe it will be inevitable ;) ___ 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 Fri, Oct 28, 2011 at 04:48:10PM +, Laws, Peter C. wrote: >> It seems like there are two ways I could delegate a zone. >> >> I could, in the zone file for the parent, simply list the name of the zone >> and a number of NS records to which the zone has been delegated. >> >> Or, I could create a zone statement within named.conf that points to a file >> that contains an SOA and a number of NS records to which the zone has been >> delegated. >> >> Which is better and which should I prefer? > Bill Owens owens at nysernet.org wrote: >If I'm reading this correctly, both ;) I take it the same servers are >authoritative for both parent and child, right? You can get away with just >creating the new zone in named.conf and not delegating it properly in the >parent, due to a quirk in BIND behavior; it always answers from its authority >and the chain of resolution will always pass through the server (because it's >authoritative for the parent). But when* you configure DNSSEC, the lack of NS >records in the parent zone will break your configuration. So installing them >now will save you that grief later. >I don't think that the order is particularly important, since queries can't be >answered until the zone is created and configured in named.conf, though I >suppose that creating the zone first is slightly more correct. Thanks. That's the bit I was looking for, SOME stuff is a quirk of BIND, like this. 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. 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. 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". :-) -- Peter Laws / N5UWY ___ 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 10/28/2011 12:48 PM, Laws, Peter C. wrote: It seems like there are two ways I could delegate a zone. I could, in the zone file for the parent, simply list the name of the zone and a number of NS records to which the zone has been delegated. Or, I could create a zone statement within named.conf that points to a file that contains an SOA and a number of NS records to which the zone has been delegated. In and of itself, that's not "delegation". Which is better and which should I prefer? Ideally, I'd like to make the zone first with the NSes pointed to the same server plus various and sundry other As and CNAMEs, but need help on this point before I do anything. BTW, this is on RHEL's BIND9 and no, the master has yet to have the RHEL bind97 RPMs installed, and yes, I am a bad admin for not doing that. No, there aren't 2 ways of "delegating" a zone. You should think of this as 2 separate functions: "hosting" a zone, versus "delegating" the zone. You can host a zone that's not delegated, but then it's not connected to the overall namespace tree, so resolvers won't be able to find it through the normal algorithm for following delegation chains. In order for anyone to resolve anything from the zone, they'd have to have specific knowledge of where the zone is hosted (or talk to something that has that explicit knowledge, or with even more levels of indirection, e.g. zones of type "forward" or "stub", but ultimately some zone-specific explicit configuration is necessary). On the other hand, you can delegate a zone and **not* *host it. This is done all the time (think gTLD or ccTLD servers delegating zones to domain registrants rather than hosting it themselves). It's kind of like the difference between having a phone line installed and publishing the number in the phone book. Some people have unlisted phone numbers (analogous to undelegated zones), and then only their friends, relatives, etc. will use it (maybe the occasional robo-caller). Or, you can publish your phone number in the phone book, so anyone generally can call you if they need to. Undelegated zones tend to be rather rare, since really the whole point of having a hierarchical namespace is so that the relevant information can be found using a relatively-simple search-within-hierarchy algorithm. Also, as others have pointed out, DNSSEC assumes normal delegation chains, so undelegated zones miss out there too. - Kevin ___ 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 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
