This chapter (The Domain Name System) has been contributed by Jason R. Fink
The Domain Name System on NetBSD. This chapter describes setting up a simple small domain with one Domain Name Server (DNS) on a NetBSD system. It does not provide a detailed overview of what DNS is, however, a brief explanation is offered. Further information can be obtained from the DNS Resources Directory (DNSRD) at http://www.dns.net/dnsrd/.
The examples in this chapter refer to BIND major version 8, however, it should be noted that the data- base format and named.conf are almost 100% compatible between version. The only difference I noticed was that the "$TTL" information was not required.
The reader should have a good understanding of basic hosts to IP address mapping and IP address class specifications.
The Domain Name System converts machine names to IP addresses. The mapping is done from name to address and address to name. The difference between just plain hosts IP mapping and Domain mapping is that DNS uses a hierarchichal naming standard. This hierarchy works from right-to-left with the highest level being on the right. As an example, here is a simple domain break-out:
TOP-LEVEL .org
|
MID-LEVEL .diverge.org
______________________|________________________
| | |
BOTTOM-LEVEL strider.diverge.org samwise.diverge.org wormtongue.diverge.org It seems simple enough, however, the system can also be logically divided even further if one wishes at different points. The example shown above shows three nodes on the diverge.org domain, but we could even divide diverge.org into subdomains such as strider.net1.diverge.org, samwise.net2.diverge.org and wormtongue.net2.diverge.org, in this case, 2 nodes reside on net2.diverge.org and one on net1.diverge.org.
Now let's look at actually setting up a small DNS enabled network. We will continue to use the examples mentioned above, before we begin we must make a few assumptions:
Our host-to-ip is working correctly
We have IPNAT working correctly
Currently all hosts use the ISP for DNS
Note: this type of configuration was described in Chapter 10.
Our Name Server will be the "strider" host, it also runs IPNAT and our two clients use strider as a gateway. It is not really relevant as to what type of interface is on strider, but for argument's sake we will say a 56k dial up connection.
So, before going any further, let's look at our hosts file on strider before we have made the alterations to use DNS.
not exactly a huge network, it is worth noting that the same rules apply for larger networks as we discuss in the context of this section.
The NetBSD Operating System provides a set of default files for you to use or go from, they are stored in /etc/namedb, I strongly suggest making a backup copy of this directory for reference purposes.
The default directory contains the following files:
127
localhost
loopback.v6
named.conf
root.cache
You will see modified versions of these files in my configuration.
The first file we want to look at is /etc/namedb/named.conf. This file is the config file for bind (hence the catchy name). Setting up system like the one we are doing is relatively simple. First, here is what mine looks like:
options {
directory "/etc/namedb";
allow-transfer { 192.168.1.0/24; };
recursion yes;
allow-query { 192.168.1.0/24; };
listen-on port 53 { 192.168.1.1; };
};
zone "localhost" {
type master;
notify no;
file "localhost";
};
zone "127.IN-ADDR.ARPA" {
type master;
notify no;
file "127";
};
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" {
type master;
file "loopback.v6";
};
zone "diverge.org" {
type master;
notify no;
file "diverge.org";
};
zone "1.168.192.in-addr.arpa" {
type master;
notify no;
file "1.168.192";
};
zone "." in {
type hint;
file "root.cache";
}; Note that in my named.conf the root section is last, that is because there is another domain called diverge.org on the internet (I happen to own it) so I want the resolver to look out on the internet last. This is not normally the case on most systems.
Another very important thing to remember here is that if you have an internal setup, in other words no live internet connection and/or no need to do root server lookups, comment out the root zone. It may cause lookup problems if a particular client decides it wants to reference a domain on the internet.
Looks like a pretty big mess, upon closer examination it is revealed that many of the lines in each section are somewhat redundant. So we should only have to explain them a few times.
Lets go through the sections of named.conf:
This section defines some global parameters, most noticeable is the location of the DNS tables, on this particular system, they will be put in /etc/named.
Following are the rest of the params:
for remote DNS servers acting as secondaries and need zone file information from you.
what network may query this name server
the port this server will run named on
The rest of the named.conf file consists of "zones", each zone has a file associated with and tables within that file for resolving that particular area (or, zone) of the domain. As is readily apparent, their format in named.conf is strikingly similar, so I will highlight just one of their records:
the type of zone in all cases except "." they are master
do you want to send out notifications when your zone changes? Obviously not in this setup.
the filename in our named directory where records about this particular zone may be found.
For the most part, the zone files look quite similar, however, each one does have some unique properties. Here is what the localhost file looks like:
Line by line:
This is the Time To Live for lookups, this is generally the same in all of the files.
This line is generally the same in all zone files except root. Of specific interest on this line are strider.diverge.org. and root.diverge.org. Obviously one is the name of this server and the other is the contact for this DNS server, in most cases root seems a little ambiguous, it is preferred that a regular email account be used for the contact information (for example, mine would be jrf.diverge.org.).
This line is the serial number, most people use the date they installed the server in a format like so: MMDDYYYY. The serial number should be incremented each time there is a change to the file after it has been initially installed. That is why I prefer to just start with 1.
This is the refresh rate of the server, in this file it is set to once every 8 hours.
The retry rate.
Lookup expiry.
The minimum Time To Live
This is the Nameserver line, as you can see it is set to localhost.
This is the local host entry.
This line is the ipv6 entry.
This is the reverse lookup file (or zone) for the localhost. It looks like this:
1| $TTL 3600 2| @ IN SOA strider.diverge.org. root.diverge.org. ( 3| 1 ; Serial 4| 8H ; Refresh 5| 2H ; Retry 6| 1W ; Expire 7| 1D) ; Minimum TTL 8| IN NS localhost. 9| 1.0.0 IN PTR localhost.
In this file, all of the lines are the same as the localhost zonefile with exception of line 9, this is the reverse lookup record. It is defined in a separate file because it is the localhost and has a totally different address than the remaining zones. Something we will discuss after looking at all of the zone files.
This zone file is populated by records for all of our hosts on the 192.168.1.0/24 network. Here is what it looks like:
1| $TTL 3600 2| @ IN SOA strider.diverge.org. root.diverge.org. ( 3| 1 ; serial 4| 8H ; refresh 5| 2H ; retry 6| 1W ; expire 7| 1D ) ; minimum seconds 8| IN NS strider.diverge.org. 9| IN MX 10 maila.diverge.org. ; primary mail server 10| IN MX 20 mailb.diverge.org. ; secondary mail server 11| strider IN A 192.168.1.1 12| maila IN CNAME strider.diverge.org. 13| samwise IN A 192.168.1.2 14| www IN CNAME samwise.diverge.org. 15| mailb 16| worm IN A 192.168.1.3
There is a lot of new stuff here, so lets just look over each line that is new here:
This line shows our mail handler, in this case it is strider, but for scaling reasons, we want to call it maila. As you will see below this is not a big deal, the number that precedes maila.diverge.org. is the priority number, the lower the number their higher the priority. The way we are setup here is if strider cannot handle the mail, then mailb (which is really samwise) will.
CNAME stands for canonical name, or in lamens, an alias. So we have aliased the following:
maila.diverge.org to strider.diverge.org mailb.diverge.org to samwise.diverge.org www.diverge.org to samwise.diverge.org
The rest of the records are simply mappings of IP address to a full name.
This zone file is the reverse file for all of the host records, the format is similar to that of the localhost version with the obvious exception being the addresses are different:
1|$TTL 3600 2|@ IN SOA strider.diverge.org. root.diverge.org. ( 3| 1 ; serial 4| 8H ; refresh 5| 2H ; retry 6| 1W ; expire 7| 1D ) ; minimum seconds 8| IN NS strider.diverge.org. 9|1 IN PTR strider.diverge.org. 10|2 IN PTR samwise.diverge.org. 11|3 IN PTR worm.diverge.org.
This file is a list of root servers for your server to query when it gets requests outside of it's own domain. Here are first few lines of a root zone file:
; $NetBSD: root.cache,v 1.8 1997/08/24 15:50:47 perry Exp $ ; ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . file" ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file /domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher at RS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; file named.root ; ; last update: Aug 22, 1997 ; related version of root zone: 1997082200 ; ; ; formerly NS.INTERNIC.NET ; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 . . .
This file can be obtained from ISC at http://www.isc.org/ and usually comes with a distribution of BIND. A root.cache file is included with the NetBSD core Operating System.
In this section we will look at how to get DNS going and setup strider to use it's own services.
NetBSD already provides a dns caching server install (shown in the next section). Along with this are the tools to manage the server at runtime. Before that can start, however, we must look at how to properly initialize the server.
Setting up named to start automatically is quite simple. In /etc/defaults/rc.conf simply go to the line named and replace NO with YES. Additional options can be specified on that line in between the quotes, for example, I like to use -g nogroup -u nobody, so a non root account runs the named process.
In addition to being able to startup named at boot time, it can also be controlled with the ndc facility. In a nutshell the ndc facility can stop, start or restart the named server process. It can also do a great many other things (see the ndc man page for more details).
The general usage is ndc.
Next we want to point strider to itself for lookups. We have two simple steps, first, decide on our resolution order. On a network this small, it is likely that each host has a copy of the hosts table, so we can get away with using hosts then dns, however, on larger networks it is much easier to use DNS. Either way, the file where this is determined is /etc/nsswitch.conf (see Example 10-2.) Here is part of a typical nsswitch.conf:
. . . group_compat: nis hosts: files dns netgroup: files [notfound=return] nis . . .
the line we are concerned with is hosts, files means the system uses /etc/hosts to determine ip to name translation. The entry on the left is the first method of resolution.
The next file is /etc/resolv.conf, this file is the dns resolution file, the format is pretty self explanatory but we will go over it anyway:
domain diverge.org search diverge.org nameserver 192.168.1.1
In a nutshell this file is telling the resolver that this machine belongs to diverge.org, should search it before looking elsewhere and the nameserver address is 192.168.1.1 .
To test our nameserver we can use several commands, for example:
# host www.blah.net
here is the output of running host www.yahoo.com:
www.yahoo.com is a nickname for www.yahoo.akadns.net www.yahoo.akadns.net has address 216.32.74.50 www.yahoo.akadns.net has address 216.32.74.51 www.yahoo.akadns.net has address 216.32.74.52 www.yahoo.akadns.net has address 216.32.74.53 www.yahoo.akadns.net has address 216.32.74.55
The procedure for setting up the client hosts are the same, setup /etc/nsswitch.conf and /etc/resolv.conf.
A caching only name server has no local zones; all the queries go to the root servers and the replies are accumulated in the local cache. The next time the query is performed the answer will be faster because the data is already in the server's cache. Since this type of server doesn't handle local zones, to resolve the names of the local hosts it will still be necessary to use the already known /etc/hosts file.
Since NetBSD supplies defaults for all the files needed by a caching only server, the configuration of this type of DNS is very easy, and can be performed with a few commands, without writing a single line in the configuration files.
Note: the number of the configuration files and their contents varies between versions of NetBSD.
The program which supplies the DNS server is the named daemon, which uses the named.conf configuration file for its setup. The default file supplied by NetBSD is located in the /etc/namedb directory, but the daemon looks for it in the /etc/ directory, so we start by creating a link:
# ln -s /etc/namedb/named.conf /etc/named.conf
The name server is ready for use! We can now tell to the system to use it adding the following line to the /etc/resolv.conf file:
nameserver 127.0.0.1
Now we can start named.
# named
Note: we have now started the name server manually. Once we have tested it and are confident that it works, we can launch it automatically at boot using the relevant option of the /etc/rc.conf file.
Now that the server is running we can test it using the nslookup program.
# nslookup Default server: localhost Address: 127.0.0.1 >
Let's try to resolve an host name, for example www.mclink.it (try a site near you.)
> www.mclink.it Server: localhost Address: 127.0.0.1 Name: www.mclink.it Address: 195.110.128.8
If you repeat the query a second time, the result is slightly different:
> www.mclink.it Server: localhost Address: 127.0.0.1 Non-authoritative answer: Name: www.mclink.it Address: 195.110.128.8
As you've probably noticed, the address is the same, but the message "Non-authoritative answer", has appeared. This message indicates that the answer is not coming from an authoritative server for the domain mclink.it but from the cache of our own server.
The results of this first test confirm that the server is working correctly.
We can also try the host command, which gives the following result.
# host www.mclink.it www.mclink.it has address 195.110.128.8