>Nothing is wrong with MS DNS server. I am using it too. One thing I'd
>love to automate the process of adding/modifying zones and records via web
>browser or some automated process. We have around 50-100 new users everyday
You mean user account's in Imail or new domains for your DNS?
>and they'd like to have third-level DNS at our site, i.e., user1.hotbiz.com.
That's called a "host" within the hotbiz.com zone.
>And I can't continue to add them manually everyday like right now.
50 to 100 new hosts and/or domains per day is 10,000 to 20,000 per year, so
you are definitely out of the "flat file" situation of named.conf and well
into a database requirement.
While I can' say "go buy this product" to help you, I can say that in BIND
with its $INCLUDE <file> directive in a sitution where you have 100's of
virtual http servers on one or several machines and 100's of virtual mail
servers on one or several machines can save tons of work (and errors).
I maintain my named.conf file in Homesite, where the named.conf file is on
a FreeBSD box and accessed by Homesite over ftp. I have my zone statements
kept on one line with the "fields" separated by tabs (acceptable whitespace
for named) so that copying a zone is "select line, down arrow, paste line",
and then, change the two occurences of the zone name on the line kept
deliberately at the front of the line:
on the master ns:
zone "meiway.com" IN {file "db.meiway.com"; type master; etc .....};
on the slave ns:
zone "meiway.com" IN {file "db.meiway.com"; type slave; etc etc .....};
What's nice about this is that when your tab spacing is set up wide enough,
you have a visually quick and simple of way of validating your work work
because the vertical columns that appear when so many identical lines are
stacked up.
And since your paste of a correct line duplicates all those braces and
semicolons, typo's are absent. Easy to "clone-a-zone" and just change the
zone name twice and onto the next new zone.
Now, what about $INCLUDE used in the db.zone files? Well, that can benefit
from tremendous commonality shared by all your zones (1000 virtual web site
on machine A and their 1000 virtual mail servers on machine B).
Here's a newdomain.com zone file of arbitrary "zone type A" built with a
"template" db.zonefile packaging all the commonality.
$ORIGIN newdomain.com
$TTL 86400
@ IN SOA ns1.hotbiz.com. ns-admin.hotbiz.com. (
2000042701 ;
86400 ;
1800 ;
864000 ;
86400 ;
)
;
$INCLUDE db.templateA
Zap!! your finished doing the newdomain.com's zone file. Just change the
serial number you're done. (It would be great to use $include to build the
SOA record, but $inlclude can't be used within a named.conf statement or
db.zone file RR.)
Here's db.templateA:
# db.templateA
;
;nameservers
@ IN NS ns1.hotbiz.com.
@ IN NS ns2.hotbiz.com.
@ IN NS ns3.hotbiz.com.
;
;mailservers (using 3 IMGate mail gateways)
@ IN MX mgw1.hotbiz.com.
@ IN MX mgw2.hotbiz.com.
@ IN MX mgw3.hotbiz.com.
;
; hosts: A RR's
;
;infrastructure hosts: nameservers
ns1 IN A 216.32.239.11
ns2 IN A 216.32.239.12
ns3 IN A 216.32.239.13
;
;infrastructure hosts: mail gateways
mgw1 IN A 216.32.239.21
mgw2 IN A 216.32.239.22
mgw3 IN A 216.32.239.23
;
; customer hosts
@ IN A 216.32.239.178
www IN A 216.32.239.178
ftp IN A 216.32.239.178
The above assumes that all domains have their incoming mail delivered to
the "mgw" machines (and then forwarded to Imail after anti-spam policies
are applied (see http://IMGate.MEIWay.com) ) and .178 is big mutha of a
machine where you have 1000 virtual HTTP servers each with ftp access for
web site maintenance. These conditions are defined as "A conditons" so the
template is called "db.templateA".
=========
Now what about those cusomter who want virtual hosts in the virtual
domains? easy, just start with their db.newdomain.com forward zone file and
add the new virtual hosts at the the end:
$ORIGIN newdomain.com
$TTL 86400
@ IN SOA ns1.hotbiz.com. ns-admin.hotbiz.com. (
2000042702 ;
86400 ;
1800 ;
864000 ;
86400 ;
)
;
$INCLUDE db.templateA
vhost1 IN A 216.32.239.178
vhost2 IN A 216.32.239.178
Anyway, you get the idea. Note that the s/n is modified also, so that when
named re-parses the zone files, it will pick up the new serial number only
for db.newdomain.com
and add vhost1 and vhost2.
Adding hosts to zone files does not require touching named.conf.
oh, by the way, all of this scriptable with batch files or PERL so highly
scaleable and portable from NT to FreeBSD or Linux, since PERL is portable
and the BIND8 config files are identical no matter what the OS.
If you want to see what a database front-end looks like for a DNS, try to
join the beta at UltraDNS.net. This DNS web admin GUI was done in Cold
Fusion. Really a very nice Web GUI, but would be nice for 50 to 100 new
zones per day?? I don't GUI is a solution for high volume zone creation.
Len
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
