From owner-freebsd-questions Fri May 4 8:17:40 2001 Delivered-To: freebsd-questions@freebsd.org Received: from clientmail.realtime.co.uk (simian.realtime.co.uk [194.205.134.131]) by hub.freebsd.org (Postfix) with ESMTP id B7B3D37B423 for ; Fri, 4 May 2001 08:17:37 -0700 (PDT) (envelope-from waynep@zaphod.realtime.co.uk) Received: from zaphod.realtime.co.uk ([194.205.134.208]) by clientmail.realtime.co.uk with esmtp (Exim 3.20 #1) id 14vhKp-0005HL-01; Fri, 04 May 2001 16:17:35 +0100 Received: from waynep by zaphod.realtime.co.uk with local (Exim 3.20 #1) id 14vhKm-000MKu-00; Fri, 04 May 2001 16:17:32 +0100 From: Wayne Pascoe To: Ceri Cc: freebsd-questions@freebsd.org Subject: Re: Purpose of serial number in zone files (BIND) References: <20010504163252.D50786@d9168.upc-d.chello.nl> <20010504160732.A1139@cartman.techsupport.co.uk> Reply-To: wayne.pascoe@realtime.co.uk Date: 04 May 2001 16:17:32 +0100 In-Reply-To: <20010504160732.A1139@cartman.techsupport.co.uk> Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ceri writes: > Sounds interesting - how are you planning to do that ? We've got 2 options at the moment. I'm leaning towards two just personally, because then it becomes easier to build tools for. 1. Keep authoritative master copies of all zone files in CVS. When changing a zone file, check the file out of cvs (locked read only), change it, check it back in, and then propogate the new file to all servers using scp. This is painful, because we are still dealing with actual zone files. More human intervention. This would have been ok when we only had a few domains. Now, it's a pain. 2. Option 2. Maintain a database with one table per zone file. Table contains several kinds of record. Status record (Changed, Unchanged, New). Host record (FQDN, TYPE (CNAME, A, NS, MX), IP), serial_num Once an hour all the servers query the database and rebuild all zone files that have changed since last check. Flags are then set back to unchanged. Also creates zone files and entries in the config table for all new zones. If the zone is new, then named is restarted. If a zone has changed, named is hupped. If no change, then named keeps ticking. That's the plan. Now to implement. Then to fix :) -- - Wayne Pascoe E-mail: wayne.pascoe@realtime.co.uk Phone : +44 (0) 20 7544 4668 Mobile: +44 (0) 788 431 1675 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message