h2n and multiple domains/zones
Mike Dimmick
mike at dimmick.demon.co.uk
Wed Mar 1 03:08:14 UTC 2000
<scott at n-a.net> wrote in message news:87qlfv$iv5$1 at nnrp1.deja.com...
> Hey,
>
> I am having trouble finding detailed info on the process of
configuring
> and maintaining an 8.2.2 nameserver while using h2n utility with
> multiple zones in linux. H2n writes over the entries in the db.ipaddr
> file when I try to use separate zone configuration files such as:
> ./h2n -f filename
>
> I was thinking about just copying and renaming the db.domain file,
> editing it with the other zone information so as to limit the risk of
> making a syntax error. Then just editing the named.conf, and the
> db.ipaddr file with the needed info. But I was wondering if anyone
knew
> of a better way. I have been looking for more information, but
> apparently from what I have read, even the man page doesn't cover
every
> configuration option. I know I can't be the only person whose run
> accross this?
Hmm. It might well be better just to throw away that tool (which, let's
face it, is only meant to convert ONE hosts file to ONE zone), and learn
how to create zone files yourself:
Decide what zones you want. You don't *have* to put all subdomains in
their own zones but it can make admin easier. Think of those areas you
might want to give admin rights to someone else eventually (my
university hasn't done the subdomain thing and as a result we have lots
of machines like eeap-1, cs-ultra, etc, etc -- ick! -- and a HUGE zone
file. As an example of how to do it badly, check aston.ac.uk).
Since you're using BIND, you should have received as part of the
distribution some HTML files. Read them. They're also available on the
web at http://www.isc.org/
OK, you know which zones you want. Now you need to create a zone file
for each one.
Here's an example zone file, which happens to be from our private domain
(I run secondary server 'dragon' [192.168.0.1] on this domain):
This is the forward domain file, and I've followed an ISC recommendation
where the file lives in /var/named/[type]/[zone-name], where type is 'se
c' because this is a secondary server, and [zone-name] is 'brook-green'.
Reverse zones (called bbb.aaa.IN-ADDR.ARPA) get called aaa.bbb, etc.
(example: mine is called /var/named/sec/192.168)
; BIND version named 8.2.2-P3 Thu Nov 11 01:20:31 EST 1999
; BIND version
root at porky.devel.redhat.com:/usr/src/bs/BUILD/bind-8.2.2_P3/src/bin/name
d
; zone 'brook-green.org.uk' last serial 1999120707
; from 192.168.0.3:53 (local 192.168.0.1) using AXFR at Wed Jan 26
21:49:18 2000
$ORIGIN org.uk.
brook-green 86400 IN SOA watson.brook-green.org.uk.
hostmaster.watson.brook-green.org.uk. (
2000012601 28800 7200 604800 86400 )
86400 IN NS watson.brook-green.org.uk.
86400 IN A 192.168.0.3
$ORIGIN brook-green.org.uk.
smtp 86400 IN CNAME hercules.brook-green.org.uk.
bounce 86400 IN A 192.168.0.140
www2 86400 IN CNAME bacon.brook-green.org.uk.
www3 86400 IN CNAME hercules.brook-green.org.uk.
news 86400 IN CNAME hercules.brook-green.org.uk.
laurie 86400 IN CNAME tidy.brook-green.org.uk.
localhost 86400 IN A 127.0.0.1
dragon 86400 IN A 192.168.0.1
the-guide 86400 IN A 192.168.0.139
jellybean 86400 IN A 192.168.0.113
[snip]
(BTW if you think the set of hostnames looks odd, that's because this is
a co-operative network, not an administered one. The extent of
administration tends to be our own workstations and servers, therefore
the hostnames are whatever the owner of the machines decides they will
be!)
Right, one step at a time:
At the top you should have a $TTL command. Here the TTL has actually
been missed out, but it was set to 86400 on the master zone file.
Next the $ORIGIN command sets the origin for all following resource
records. Setting it to org.uk. here allows the SOA record (which is
long anyway) to be abbreviated to brook-green rather than the full
brook-green.org.uk.
A quick point about terminating '.' characters in Fully Qualified Domain
Names (FQDNs). If you include a terminating '.', the domain name or
current origin is *not* added on. Conversely, if you don't include one,
the domain name *is* added on. Use them where you need to, don't where
you don't. A lot of errors can be caused by getting it wrong (like
specifying an FQDN but forgetting the '.' means you end up with a
hostname looking like 'dragon.brook-green.org.uk.brook-green.org.uk'!)
Now something that actually does something, the Start of Authority
record. You should have ONE per zone (and therefore with BIND one per
file). This says who's responsible for maintaining the zone, the
primary name server (that holds the original of this file), etc.
Let's look at it closely, first line:
brook-green 86400 IN SOA watson.brook-green.org.uk.
hostmaster.watson.brook-green.org.uk. (
LTR, zone name, TTL for zone, this is an INternet zone, the Start of
Authority record, zone hosted by Watson, and contact address is
hostmaster at watson.brook-green.org.uk. (Don't try it, it won't work).
Note that the '@' in the email address is replaced by a . in the zone
file. The RFCs on DNS explain why.
The ( at the end of that line does a line continuation (though you can't
specify it before this point, I'm not sure why!), for the next section:
2000012601 ; Serial number
28800 ; refresh
7200 ; retry
604800 ; expire
86400 ) ; TTL
All values are in seconds, *apart* from the serial number. Most people
use a serial number like YYYYMMDDvv, representing the date last changed
and a version number for that day, but you can use any system you like
(for example, you might use seconds since 1970 - use date(1) to generate
this). All that matters is that they increase. You can't go back in
time. You should ensure that any time you change any part of the file,
you also change the serial number, otherwise secondary servers won't
know you changed the zone, and won't demand a new copy (or will discard
the copy they get pushed).
The other figures are for use with secondary servers and caches too,
they control how long things hang around for...
Refresh determines how often secondary servers should attempt to obtain
a newer zone file, if one is available. This value is in seconds, here
it's 8 hours, or 3 times a day. Retry determines how often they should
try again if they fail to contact; here, 2 hours.
Expire tells secondary servers how long before they should discard this
zone completely. You want this to be long in case you have a very long
outage on your primary name server - this is a week, which is actually
quite short. I'm not sure what happens if this actually does expire; I
*think* the secondary server will go off and look up the zone from the
root domain '.' until it finds a new authority for the zone, but I'm not
entirely sure.
Finally TTL stands for Time-To-Live, and controls how long a cache
server may hold a copy of this zone before it should refresh it. The
cache is perfectly entitled to discard it earlier, from what I recall.
The final ')' is to terminate the line continuation.
Right, that's the end of the SOA record, now let's look at something
that actually specifies a host:
Firstly, you should specify the name servers that are authoritative for
the zone. Leaving the first field blank means 'use the last', so a pair
of lines
IN NS watson.brook-green.org.uk.
IN NS dragon.brook-green.org.uk.
means that watson and dragon are authoritative for the zone
brook-green.org.uk. If you're not doing a private network, you should
try to ensure that your nameservers live in different parts of the
Internet, so only a massive outage will take out your nameserver
provisions. Here, our name servers live at entirely different ends of
the network, which helps. This tends to mean you should arrange to have
your names hosted by two different companies/organisations, if at all
possible.
To ensure these can be found, it's a good idea to specify their IP
addresses now...
watson IN A 192.168.0.3
dragon IN A 192.168.0.1
If you create subzones, hosted by other servers, refer to them here...
mac IN NS master.mac.brook-green.org.uk.
master.mac IN A 192.168.0.4
Now, you may want to insert some Mail eXchanger RRs. These look like:
IN MX 10 dragon.brook-green.org.uk.
IN MX 20 hercules.brook-green.org.uk.
which means that dragon is preferred, while hercules will be used if
dragon is unavailable. Use a bit of a step (say 10) initially so you
can insert new Mail servers in between if necessary. This probably
needs some consultation with Sendmail's documentation to ensure you can
get all the mail delivered where it needs to go, although redundancy is
a Good Thing.
Now you can start inserting all your normal address records.
Finally you should consider inserting canonical names for your web
server, etc. This is done with the CNAME resource record. There are
some in the list above.
Now, you should tackle the reverse lookups. These look exactly the same
as above, but:
* Your base zone is now bbb.aaa.IN-ADDR.ARPA;
* The only legal RR apart from SOA and NS is the PTR.
PTR is used to map an IP address to ONE hostname. Each IP address can
only be mapped to one hostname in the reverse lookup (however multiple
IP addresses can map to the same hostname).
You also need to put the IP addresses in *backwards*.
This is illegal:
$ORIGIN 168.192.IN-ADDR.ARPA
1.0 IN PTR dragon
1.0 IN PTR ns2
This is legal:
1.0 IN PTR dragon
2.0 IN PTR dragon
(if dragon has addresses 192.168.0.1 and 0.2 allocated to two ethernet
cards, for example)
It is possible to subdivide the reverse zone authority according to your
netmask; the way you do it, from what I understand, is to put things
like:
$ORIGIN 0.168.192.IN-ADDR.ARPA
0/25 IN SOA watson.brook-green.org.uk. hostmaster. [etc]
to give this zone authority for IP addresses in the range 192.168.0.1 to
192.168.0.126 (0 and 127 being reserved for network number and broadcast
address respectively) -- this is for 25 bits of netmask.
To access the higher section (129 thru 254), I *think* you do:
128/25 IN SOA [etc]
but I'm not sure about this! Someone else will have to clarify.
Finally, in your named.conf, do something like:
options {
// directory you put the zone files in
directory "/var/named";
};
//
// brook-green.org.uk secondary name server
//
zone "brook-green.org.uk" {
// note you don't put a trailing '.' in named.conf
type slave;
file "sec/brook-green";
masters { 192.168.0.3; };
}
zone "168.192.in-addr.arpa" {
type slave;
file "sec/192.168";
masters { 192.168.0.3; };
};
zone "0.0.127.in-addr.arpa" {
// reverse lookup for 'localhost'
type master;
file "pri/127.0.0";
};
zone "." {
// include this zone for a connected network, I have this
// commented out
// this allows caching from what I recall
type hint;
file "hint/root";
// hint/root should be 'dig'ed out of another server or you
// can ftp from rs.internic.net I think
};
For all the options please see named's man page. There are lots of
them.
I hope this helps!
--
Mike Dimmick
More information about the bind-users
mailing list