Re: [cobalt-users] Colo says need scond server

[Kris Dahl <krislists@xxxxxxxxxxxxx>]

on 7/13/00 12:27 PM, Jeff Lasman at jblists@xxxxxxxxxxxxx wrote:

> Gerald Waugh wrote:
> 
>> I don't understand, doesn't refresh update the SOA records of the Secondary
>> (slave) with the records of the Primary? And don't those records contain
>> records
>> for the sites?
> 
> My understanding is that refresh works on a zone-file basis, and that
> slave servers must have an /etc/named.conf file that shows all the
> domains being slaved, in the form:
> 
>> zone "movie.edu" in {
>> type slave;
>> file "db.movie";
>> masters {192.249.249.3; };
>> };
> 
> (Above sample quoted from the book "DNS and Bind", O'Reilly, by Paul
> Albitz & Cricket Liu, page 87.)
> 
> The key question is how do we AUTOMATICALLY get that into the file
> without human intervention.

Well, if you are using a Raq, you just add a secondardy name service for the
domain and it will create these lines in /etc/named.conf, as well as create
/etc/named/sec.whatever.com file.  From then on out the transfers of the
info are automatic.

> Once it's in the file, and the daemon is restarted, yes, the slave
> nameserver will get the file at whatever interval is in refresh.

You don't need to restart the daemon--just do a '/usr/sbin/ndc reload'.
This has BIND reparse all the files.  By adding the record and saving
changes in the Cobalt interface, it will automatically do this for you.
Additionally if it doesn't have the record (i.e. it is new) it will snag the
zone file automatically after parsing the named.conf

> Every time I've seen this question asked, the answers always revolved
> around using various ftp and other solutions to get the
> "/etc/named.conf" from the master file, and then rename it.

You want your secondary server to automatically create a secondary record
whenever you add one to the primary?  I suppose you could do this by parsing
the primary's named.conf file (or on the raqs, you could do it with the
records file) and checking to see all the domains/zones that it is primary
and then create applicable secondary records.  It would not be hard to do.
You could even create a symbolic link to make the named.conf file publically
readable via http, parse it with a perl script and output the named.conf
file for the secondary server.

Certainly doable, would take 2-3 hours to do probably.  But I think it would
be easier to just create the primary record on the primary dns server,
create the secondary record (which entails typing the domain, and the ip of
the master server).  Viola, done.

Only downside is that you would lose some flexibility on the 'slaves', or
you would have to invest some time to write some additional features to
preserve existing or outstanding records on the 'slave'.

> However, to use an automated solution you'd need to presume you were
> secondarying everything that appears on the primary server.  We don't
> presume that; we ask our clients to tell us what they want slaved.

This is certainly the safest, and IMHO the best way to go.  It is
realatively low-maintaince and offers the best flexibility.

-k