+1 to all of Chris' suggestions, especially the bit about including one
file in named.conf, and including the per-zone files in that file. Makes
it much easier to update that file with a script, or what have you.
hth,
Doug
On 02/17/2012 07:11, Chris Buxton wrote:
> Yes, it's quite possible to split named.conf into separate per-zone .conf
> files and then 'include' them back into named.conf. You can even put the list
> of include statements in a separate file, and then include that into
> named.conf.
>
> named.conf:
>
> options {
> [...]
> }
> include "/path/to/etc/zones.conf";
>
>
> zones.conf:
>
> include "/path/to/etc/zone1.conf";
> include "/path/to/etc/zone2.conf";
> [...]
>
> I've seen this done with hundreds of thousands of zones. Performance does not
> seem to be significantly impacted by breaking up named.conf into included
> files. The loading time for named in this case will be dominated by the time
> load actual zones, which involves allocating memory and building a tree
> structure in memory.
>
> Use the latest versions of BIND for fastest loading of this number of zones.
> See Evan Hunt's blog posts on the topic:
>
> http://www.isc.org/community/blog/201107/major-improvement-bind-9-startup-performance
> http://www.isc.org/community/blog/201107/isc-bind-981b3-provides-startup-performance-improvements
>
> Regards,
> Chris Buxton
> BlueCat Networks
>
> On Feb 17, 2012, at 1:24 AM, Nick Edwards wrote:
>
>> Hi,
>> In a recent discussion on another list, it was discussed the pros and
>> cons of splitting the main conf file to a per domain.
>>
>> In binds case it would be to /etc/named.d/*.conf
>> So each zone would have a file in that directory containing only the
>> relevant info
>> eg:
>>
>> zone "example.com" {
>> type master;
>> allow-transfer { slavesdns; };
>> file "example.com.signed";
>> allow-query { any; };
>> allow-update { none; };
>> };
>>
>> thats it, nothing more, rather than having 2000 entries in named.conf,
>> we would have 2000 conf file to be read (yes in addition to the 2000
>> actual zone files.
>>
>> with apache it takes only 2 or so more seconds to start and reload
>> doing it this way, so I know that bind will take longer, it has to
>> with all those open/read/close files, at present bind starts up in
>> about 9 seconds due 17K zones, so I'd imagine this would take even up
>> to 15 seconds.
>>
>> My question is, has anyone done this with success or failure?
>> Would a named developer know if its safe or detrimental to do this?
>> or would it simply make no difference apart from the extra time for
>> starts/reloads?
>>
>>
>> (This came about on another list, because we load all hosts on apache
>> in one file (2000 per box) recently something went wrong with sshfs
>> during a transaction, and in deleting a vhost block it took out about
>> 100 of them :) so we are looking at making things a bit more
>> failsafe, my opinion is, if it can happen once, it can happen again,
>> it could have happened to a zone file, but luckily only the web conf
>> file.
>>
>> Thoughts anyone?
>>
>> Thanks
>> Niki
--
It's always a long day; 86400 doesn't fit into a short.
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
_______________________________________________
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
