bind with mysql

Chris Buxton cbuxton at menandmice.com
Fri Apr 4 16:45:13 UTC 2008


Either one would work. Or you could use an off-the-shelf management  
system as a back-end, and simply design your web interface to write to  
it.

One problem you'll have is configuring the slaves. The slave servers  
will need to be configured for each zone (each domain), individually,  
which requires some kind of agent on each slave that can be driven  
from the web interface - in other words, the web interface needs to be  
able to manage all of your servers, not just the master.

I'll try to keep the sales pitch to a minimum here, but it doesn't  
make sense to me to reinvent this wheel when proven management systems  
exist that can take care of these details for you.

Chris Buxton
Professional Services
Men & Mice

On Apr 4, 2008, at 8:47 AM, J. Peng wrote:
> Thanks so much for Bill and Chris. Your answers were so professional,
> that let me learn a lot.
> We have the plan to provide business domain hosting. I don't know the
> actual amount for the domains and zones, but we current time have 200
> million registered users on other products.
> So as you see we're a large internet service provider. I assume there
> will be lots of customers to use our domain hosting too.
>
> Following your suggestions, I think the database drived BIND is not
> suitable since it's going with poor performance.So I think about the
> first architecture:
>
>                                                             --->
> slave 1 (standard BIND)
>                                                            |
> web interface --->  BIND+Mysql (master)  | ---> slave 2 (standard  
> BIND)
>                                                            |
>                                                             --->
> slave 3 (standard BIND)
>
> There are one master and more than one slaves.
> master is running with database drive, but it doesn't provide services
> to public.
> master only updates the records and zones, primarily done by web
> interface programs.
> slaves are standard BIND, when master is updated, it notify slaves to
> update their own zone records, with standard bind data transfer
> way.all slaves provide DNS service to public directly.
>
> Is this the good architecture for both performance and conveniences?
>
> If that is not good way yet, I could go with the second architecture,
> to make master to run without using DLZ, but use the standard BIND
> config files. Under this architecture, the management programs are a
> little complicated. rather than inserting and updating database
> directly, they need to parse and modify BIND's config files. But as
> Chris said, it's not so hard. Perl is strong enough for this work I
> may think.
>
> So, what's the best solution for me? the first architecture or the
> second one, or neither of them?
>
> Thank you so much for your further suggestions.
>
> B. Regards,
> Joy Peng
>
>
>
> On Fri, Apr 4, 2008 at 2:43 AM, Chris Buxton  
> <cbuxton at menandmice.com> wrote:
>> I would tend to recommend that you look at management products  
>> available
>> before reinventing the wheel.
>>
>> As noted by Bill Larson, using a database-driven system like this,
>> especially if you try to get BIND to read directly from the  
>> database (using
>> DLZ), can be quite problematic. It might be better to examine a  
>> third-party
>> management system that can be customized to meet your needs.
>>
>> If you are interested in discussing how Men & Mice Suite can be  
>> used for
>> your project, please contact me off list.
>>
>> Chris Buxton
>> Professional Services
>> Men & Mice
>>
>>
>>
>> On Apr 2, 2008, at 11:44 PM, J. Peng wrote:
>>
>>> I want to setup a pair of bind (a master and a slave).
>>> This pair of bind will have lots of zones, in each zones there are  
>>> at
>>> least some A records and MX records.
>>> I think I can setup a mysql for those records for bind master.
>>> Also I can setup mysql replication and use mysql slave for bind  
>>> slave.
>>> Is this good resolving way? please suggest, thanks.
>>>
>>>
>>
>>
>



More information about the bind-users mailing list