Best practice for zone with resonable amount of subdomains

Barry Margolin barmar at alum.mit.edu
Thu Dec 14 05:35:18 UTC 2006


In article <elo75o$10hl$1 at sf1.isc.org>, jm <jm at hcn.com.au> wrote:

> Hi All,
> 
> Just seeking input on peoples thoughts here.
> 
> I have one particular zone that has ~500 subdomains. Each subdomain has 
> an A record and a www CNAME.
> 
> I've considered 3 possible ways to structure the data being:
> 
> 1. create a single master zone file and symlink the rest to it.
> 2. a single zone file & the use of $ORIGIN
> 3. writing the zone file as follows:
> 
> aaa    IN    A    xxx.xxx.xxx.xxx
> www.aaa   IN   CNAME    aaa
> bbb    IN    A    xxx.xxx.xxx.xxy
> www.bbb    IN    CNAME bbb
>         
> My personal choice would be symlinking but some others have disagreed.
> 
> What's best practice?

I don't see how the symlink solution would work for this.  Based on the 
above example, the address of the server for each subdomain is different 
(aaa's address ends in xxx, bbb's address ends in xxy), so you can't use 
the same zone file for each zone.  Was that a typo in the example?

Anyway, I would probably go with solution 3.  If you create separate 
zones for each subdomain, it means that whenever you add or delete a 
subdomain you'll need to modify the named.conf on all the slave servers 
as well.  By using a single zone, the updates will be transferred 
automatically to the slaves by normal zone transfers, so you only need 
to update it in one place.

Solutions 2 and 3 are basically the same, but I'm not a big fan of 
$ORIGIN -- I think it makes zone files harder to read.  It might be OK 
if you have a large section of the file that's in a subdomain, to avoid 
repeating that part of the name over and over, but I don't see any point 
to using it for just two lines -- it means each two-line block will 
become a 3-line block.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***



More information about the bind-users mailing list