DNS cluster

Kevin Darcy kcd at daimlerchrysler.com
Thu Jul 7 22:08:30 UTC 2005


That seems like overkill to me. Why keep all of the actual *zone*data* 
in a database, when all you really need (according to the original 
poster's requirements) is a *list*of*zones*. You don't need MySQL just 
to store a list that's likely to be, at most, only a few thousand, 
perhaps tens of thousands of small entries. That list can be a simple 
text file. Or, represent each zone name as an RR in a special "index" 
zone -- that way you don't need to open up holes in your firewall for 
anything beyond DNS itself. Once you have a script that keeps the 
named.conf on the slaves automatically up to date, the actual zone-data 
replication/propagation can be done through the standard AXFR/IXFR 
mechanisms.

As for putting a GUI on the maintenance of zone data itself, my 
preference is to use Dynamic Update for the backend. Why 
install/configure/run/maintain a separate database package, when your 
nameserver already has one basically built into it? One that's optimized 
for DNS, can be secured via TSIG, etc....

                                                                         
                                                                        
- Kevin

Genco YILMAZ wrote:

>Hi Stelios,
>I had written a BIND-GUI in php and backend perl to manage zone files.
>In fact, this software changes the way master and slave concept a little
>bit. All zone files are kept in a MySQL database. When you add a new
>zone into the master dns server through GUI, all other client dns
>servers fetch new zone files or any changed data with the client
>software written in perl.  Perl clients make a tcp connection to the
>database server through an encrypted tunnel connection and write the new
>data into the normal text files.  When you write a cron entry on the
>master and client dns servers all data is spread into client dns
>servers. This allowed me to play with zone files because in this
>structure every client is a master server functionally. GUI allows any
>change on the zone records kept in database.
>    In fact I have implemented this structure for me but If anybody
>needs this, after a little documentation it can be ready for any own system.
>Kind Regards.
>
>Stelios Asmargianakis wrote:
>
>  
>
>>Hi Brad,
>>
>>Thanks for your answer.
>>Using rsync is not the problem and I can copy the zones easily and then
>>reload the dns; the problem comes that I need to edit each time the
>>named.conf on the 2nd server manually. This is impossible as we are talking
>>for many entries in DNS every week.
>>
>>Any other ideas?
>>
>>Regarding with Peter Alberchts reply (thanks for that) using webmin or any
>>other GUI is not the solution as I am trying to find something to do the job
>>automatic.
>>
>>Unfortunately it seems that I will need to stuck with 2 dns servers both
>>with cpanel (it's a web hosting control panel).
>>
>>Thanks
>>
>>-----Original Message-----
>>From: Brad Knowles [mailto:brad at stop.mail-abuse.org] 
>>Sent: Thursday, July 07, 2005 1:01 PM
>>To: linux at climbincrete.com
>>Cc: bind-users at isc.org
>>Subject: Re: DNS cluster
>>
>>At 12:25 PM +0100 2005-07-07, Stelios A. wrote:
>>
>> 
>>
>>    
>>
>>>I am trying to set up a DNS cluster using a traditional master-slave but
>>>   
>>>
>>>      
>>>
>>I
>> 
>>
>>    
>>
>>>cannot find a way to add the appropriate entries in named.conf on the
>>>slave DNS (master will run linux with cpanel control panel installed).
>>>   
>>>
>>>      
>>>
>>	There's no standard way to automatically distribute changes to 
>>named.conf, at least not so far as I know.
>>
>> 
>>
>>    
>>
>>>That means that although the zone files would automatically synchronise,
>>>however I would have to manually add new zone entries to named.conf on
>>>   
>>>
>>>      
>>>
>>the
>> 
>>
>>    
>>
>>>2nd box (linux no control panel).
>>>   
>>>
>>>      
>>>
>>	Yup.  That's a well-known problem.
>>
>> 
>>
>>    
>>
>>>Any ideas how to achieve that?
>>>   
>>>
>>>      
>>>
>>	You could set up something like rsync or ssync (rsync over ssh), 
>>pull the configuration files out of a database on all machines, or 
>>any number of other alternatives.
>>
>> 
>>
>>    
>>
>
>
>  
>




More information about the bind-users mailing list