One Newbie, totally confused

[Kevin Darcy]

Slackr wrote:
> 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?
>   
Simplistically:

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 
overrides".
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.

                                                                         
                                    - Kevin