One Newbie, totally confused
kcd at daimlerchrysler.com
Tue Oct 3 00:56:51 UTC 2006
> I want to create a bind-based setup for www.domain1.com, a.domain1.com
> for host 127.0.0.1
> (obviously these aren't the real addresses)!
> Can I get anyone's help?
1. Define the domain1.com zone in your named.conf as "type master".
2. Populate the zone file with "www" and "a" entries (in addition to the
required entries like SOA and NS).
3. Configure the rest of the master's BIND environment:
a) start named automatically on reboot
b) log messages of interest to syslog or directly to a file
c) set up rndc so that you can control the daemon
d) set up named to run unprivileged and/or chroot'ed
e) if you expect to be changing the zone fairly frequently, such
that manually editing zone files (followed up by incrementing the zone's
serial number and telling named, via rndc, to reload it) is bound to
become impractical, set up some sort of change mechanism, be it a
version-control, source-code-control system like RCS, a web frontend
with a Dynamic Update backend (as we have), webmin (look it up), or for
heavier-duty stuff, look into BIND's "SDB" extensions, so that you can
use as your BIND data store a relational database, an LDAP directory, or
something along those lines (note that I've never actually worked with
SDB, but other people on this list have). At the "enterprise" level, you
don't need to abandon BIND, since the DNS component of some of the
leading "address management" products, like Nortel's NetID or Lucent's
QIP, are, under the covers, just modified versions of BIND.
4. Set up 1 or more other nameservers to slave the zone from the master
server by adding a "type slave" definition to their named.conf, along
with the necessary "environmental" configuration (see #3a through #3d
above), and publishing those slaves in the set of NS records at the apex
of the zone. You might also want to consider setting up TSIG-based
authentication between the masters and slaves for enhanced security.
5. Optionally, set up caching resolvers that have the ability to resolve
names in the domain1.com zone. If domain1.com is in the normal
delegation hierarchy that your caching resolver would use, then this is
somewhat trivial, but if it's not -- e.g. if your caching resolver uses
the Internet DNS, but domain1.com is not registered in, or
registered-in-but-not-delegated from the Internet DNS -- then you'll
have to explicitly define domain1.com in the caching resolver, either as
"type stub", "type slave" (if it's a slave but not a published one, we
call that a "stealth slave", by the way), or "type forward". The choice
of whether to use stub, slave or forward for any given zone is a
non-trivial one, depending on factors like basic network connectivity,
bandwidth, depth of delegations, query traffic patterns and volume,
cache-persistence settings, the permission(s) of your server(s) to make
certain categories of queries (zone transfer, recursive) to other
servers, and/or availability expectations, among others. Generally
speaking I'd go with "type stub" if possible, for these "delegation
6. Finally, configure -- probably via DHCP -- your clients ("stub
resolvers") to use some combination(s) of master, slave(s) and/or
caching-resolver(s) for resolving all of their DNS names. As long as
your clients are talking only to nameservers/resolvers that either a)
are authoritative (master or slave) for domain1.com, or b) have explicit
configuration that allows them to resolve domain1.com names, or c) can
find domain1.com via the normal delegation hierarchy, then they
shouldn't have any problems resolving domain1.com names.
(Note that you only said "create a bind-based setup"; you didn't say
anything about publishing your domain1.com information to the Internet
or to an intranet with its own internal root. So I haven't included any
of those domain-registration-and/or-delegation steps in the sequence above).
I'd recommend procuring and reading _DNS_and_BIND_ (Fourth or Fifth
Edition) from O'Reilly. It's more-or-less the "bible" on the subject.
More information about the bind-users