zone before delegation?
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? 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. -- 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 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
