Date: Mon, 07 May 2001 10:21:48 +1000 From: Tony Landells <ahl@austclear.com.au> To: wayne.pascoe@realtime.co.uk Cc: freebsd-questions@FreeBSD.ORG Subject: Re: Purpose of serial number in zone files (BIND) Message-ID: <200105070021.KAA01476@tungsten.austclear.com.au> In-Reply-To: Message from Wayne Pascoe <wayne.pascoe@realtime.co.uk> of "04 May 2001 16:17:32 %2B0100." <m166fhdtyr.fsf@zaphod.realtime.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
wayne.pascoe@realtime.co.uk said: > 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 :) It's certainly an interesting concept... I've thought of doing similar things myself, but the implementations I've seen so far have all been of questionable quality so I've just stuck with doing it by hand. But I have seen lots of people who should know better break DNS by, for example, starting a comment in a zone file with a hash instead of a semicolon. Usually the first sign is when someone else tells you your DNS is broken. You're looking at a fairly substantial project here if you really want to get it right. For example, you have to check that the host names entered are valid (should be possible with either method). You also have to check that MX records don't refer to CNAMEs, that you don't have CNAMEs multiply defined, ... I would suggest that if you're going to do this that you should create/update the data on a system that doesn't actually do name service. That way, you can just load the zone and check BIND's log for error messages rather than trying to second guess BIND in your own scripts. That way you have a chance to reject changes before they've been committed (but you still have the data file as a starting point for the person to revise their changes). The other thing you have to be careful of is what your parent name servers do. Current "best practice" is to put the master name server in the SOA, and when you request delegation of a zone (or a change of delegation) your parent may check this on each name server (even though the theory is that it's effectively a comment field) and reject your request if they don't match. Personally, I think my strategy would be to rely on BIND to do the zone transfers, and worry about: 1. scripting something to tell the servers which zones they should have; 2. validating the data going in to the master server(s). It is true that zone transfers can be used for attacks, but that can be tightened up, and if you're still concerned about it perhaps the "socially responsible" approach would be to contribute time to the BIND effort to fix zone transfers. Cheers, Tony -- Tony Landells <ahl@austclear.com.au> Senior Network Engineer Ph: +61 3 9677 9319 Australian Clearing Services Pty Ltd Fax: +61 3 9677 9355 Level 4, Rialto North Tower 525 Collins Street Melbourne VIC 3000 Australia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105070021.KAA01476>