The setup will include both an caching name server and an internal network
DNS resolution method. If you want to use NFS server in linux, you will need
the DNS server working with the internal network. The NFS requires that a
host be identified by its domainname and then be able to resolve it's IP
address via DNS.
A DNS Overview
The DNS hierarchical tree structure begins with Top Level Domains (TLDs).
The best known TLDs are ORG, COM, EDU, and NET. Just like a tree structure,
domains branch off from these TLDs.
For instance, if you want to find the address of prep.ai.mit.edu, your name
server has to find a name server that serves the .edu domain. It asks a "."
server (which is specified in the root.hints file) to give a list of servers
that serve the edu servers. It then works it's way up the tree asking each
consecutive node about the next node.
> server c.root-servers.net
Default Server: c.root-servers.net
Address: 192.33.4.12
> set q=ns
> edu.
This will report all the ROOT-SERVERS.NET servers serve the EDU. domain.
We will continue asking the c.root-servers.net server...
> mit.edu.
Look for the "Authoritative answers can be found from:" area and use one of
these servers for your next query. They are the servers which know about the
domains within the mit.edu. domain.
> server W20NS.mit.edu.
> ai.mit.edu.
Find the "Authoritative answers..." line and once again, set one of these
nameservers as the querying nameserver. Remember, these nameservers are
familiar with the ai.mit.edu domain. We are working our way up the tree.
> server MUESLI.AI.MIT.EDU
We are now in the domain in which we want detailed information about.
Therefore we will set the query type to 'any'.
> set q=any
> prep.ai.mit.edu.
What we have done is work our way up the domain tree starting at the root
".", if we had simply queried the nslookup for "prep.ai.mit.edu", the named
daemon would have simply worked it's way up the tree as we did here. The DNS
system starts with root servers (ROOT-SERVERS.NET) that are specified in the
root.hints file.
Reverse Lookups
If you query an IP address from nslookup, you will get the domain name for
that IP address, this is called a reverse lookup. The "in-addr.arpa" domain
allows for reverse lookups. IP addresses are written in reverse order in the
in-addr.arpa domain. So, when a DNS server queries an IP address for a
reverse lookup, it starts with the root servers (arpa.) and works it way
up the IP address similar to the normal DNS query. For example to reverse
lookup query an IP address of 192.128.52.43, the process would be as
follows...
arpa.
in-addr.arpa
192.in-addr.arpa
128.192.in-addr.arpa
52.128.192.in-addr.arpa
43.52.126.192.in-addr.arpa
Creating Our Own Domain
If you do not have your own domain, use a domain that is definitely
non-existant as to not disturb real domains. We will use "linux.lan" in
this example.
In the named.conf file, we had the zone called "0.0.127.in-addr.arpa" which
read as follows...
named.conf:
zone 0.0.127.in-addr.arpa {
type master;
file "127.0.0";
};
127.0.0:
@ IN SOA linux.lan root.linux.lan (
1 ; Serial
8H ; Refresh
2H ; Retry
1W ; Expire
1D) ; Minimum TTL
@ IN NS ns.linux.lan.
1 IN PTR localhost.
The 127.0.0 file is the primary record for this domain. This file contains
the "resource records" or RRs. An SOA, NS, and PTR resource record. The
SOA stands for "Start Of Authority", the NS stands for "Name Server",
resource record which tells DNS what the name server is for this domain.
The PTR resource record indicates that the host at address 1 in the subnet
"127.0.0.0" is named localhost (127.0.0.1). This is where the server name
comes from when you query the default server. For example...
% nslookup
> www.yahoo.com
Name: localhost
Address: 127.0.0.1
See the "Name: localhost", this comes from the PTR record which stated that
the name was "localhost".
Next we will create a new zone for our "linux.lan" domain.
named.conf:
zone "linux.lan" {
notify no;
type master;
file "linux.lan";
};
Notice the use of "notify no;", we have not used this until now. The notify
denotation of no tells named not to notify the secondary or slave DNS server
when it gets updates about domainnames. This is not necessary in a private
network.
linux.lan:
@ IN SOA ns.linux.lan. hostmaster.linux.lan. (
200011151 ; Serial, date + serial
8H ; Refresh, seconds
2H ; Retry, seconds
1W ; Expire, seconds
1D) ; Minimum, seconds
TXT "Linux.lan, your DNS consultants"
NS ns ; Inet Address of Name Server
NS diamond.linux.lan. ; Secondary DNS Server
MX 10 mail ; Primary Mail Exchanger
MX 20 diamond.linux.lan. ; Secondary Mail Exchanger
localhost A 127.0.0.1
ns A 192.168.1.10
www CNAME ns
mail CNAME ns
ftp CNAME ns
In the linux.lan file, the ns.linux.lan. must be an actual machine name with
an "A" record (it cannot be an alias or CNAME). You cannot have a CNAME
record for a machine that will be specified in a SOA record. The MX record
specified in the above example stands for "MaileXchanger" RR. It tells mail
systems how to send mail that is addressed to "user@linux.lan". The number
just before the machine name in the MX record is the MX RRs priority. The
RR with the lowest number is the machine that should receive mail (or try
to contact first).
Another difference in the above file is the use of "mail" and
"diamond.linux.lan.", if you use just the machine name, all you have to
do is put the name. If you give the fully qualified domain name, you need
to end it with a period which specifies that it is a fully qualified domain
name. If you didn't put a period after the diamond.linux.lan name, it would
be interpreted as "diamond.linux.lan.linux.lan" just as 'mail' is interpreted
as "mail.linux.lan".
Now, try the nslookup again with query set to all...
% nslookup
> set q=any
> linux.lan
You should get a large amount of data from this query about your local
network.
Creating A Reverse Zone
A reverse zone is required by some services to decide if they want to allow
you to connect to them. This reverse IP to hostname lookup is often used by
FTP, IRC, WWW, and other services as a security mechanism. Remember the
hosts.deny and hosts.allow files, if you put a domain in them, they must be
able to resolve your IP address to the hostname to decide if you are allowed
to access the services on the machine. If they have no way of getting
information about your domain from your IP address, they will most likely
deny access.
named.conf:
zone "1.168.192.in-addr.arpa" {
notify no;
type master;
file "1.168.192"
};
1.168.192:
@ IN SOA ns.linux.lan. hostmaster.linux.lan. (
200011151 ; Serial
8H ; Refresh
2H ; Retry
1W ; Expire
1D) ; Minimum TTL
NS ns.linux.lan.
1 PTR localhost.
2 PTR ns.linux.lan.
3 PTR diamond.linux.lan.
4 PTR mail.linux.lan.
5 PTR ftp.linux.lan.
In order for a reverse lookup to work correctly on a fully qualified domain
name, you must ask your service provider to update their NS records for your
reverse zone as well as for your forward zone. If you follow the chain from
in-addr.arpa to your net you will probably find a break in the chain. This
break will most likely be at your service provider who allocated the IP
addresses to you.
Ask Mr. DNS:
http://www.acmebw.com/askmrdns/00007.htm
A Detailed Zone File Example:
linux.lan:
@ IN SOA ns.linux.lan. hostmaster.linux.lan. (
200011151 ; Serial, date + serial
8H ; Refresh, seconds
2H ; Retry, seconds
1W ; Expire, seconds
1D) ; Minimum, seconds
TXT "Linux.lan, your DNS consultants"
NS ns ; Inet Address of Name Server
NS diamond.linux.lan. ; Secondary DNS Server
MX 10 mail ; Primary Mail Exchanger
MX 20 diamond ; Secondary Mail Exchanger
localhost A 127.0.0.1
gw A 192.168.1.1
HINFO "CIsco" "IOS"
TXT "The Router"
ns A 192.168.1.10
MX 10 mail
MX 20 mail.linux2.lan.
HINFO "Pentium" "Linux 2.2"
www CNAME ns
mail A 192.168.1.4
MX 10 mail
MX 20 mail.linux2.lan.
HINFO "386sx" "Linux 1.2"
ftp A 192.168.1.5
MX 10 mail
MX 20 mail.linux2.lan.
HINFO "P6" "Linux 2.1.86"
In the detailed zone file example above, there are a number of new resouce
records (RR) used.
HINFO - Host INFOrmation - Hardware or CPU + Software or OS
CNAME - Canonical NAME - Assigns aliases
The use of CNAME records can be dangerous. Many DNS administrators recommend
not using CNAME records at all. The following rules apply to CNAME RRs...
1. An MX, CNAME, or SOA record should never refer to a CNAME record:
www CNAME ns ; YES!
server CNAME www ; NO!
server CNAME ns ; YES!
2. A CNAME is not a legal host name for an email address:
"webmaster@www.linux.lan" is an illegal email address.
To avoid the use of a CNAME, use A (or perhaps MX) records instead:
www A 192.168.196.2 ; Same as NS!
If you create a detailed zone file such as this, you can query it with
nslookup to see the results...
% nslookup
> ls -d linux.lan
> set q=any
> www.linux.lan.
Notes:
To round-robin different IP addresses for the same domain to balance the
load on mail serves and give some high-availablity effect, make several
"A" records for your domain with different IP addresses.
For a secondary name server, put another entry in the named.conf file...
named.conf:
zone "linux.lan" {
type slave;
file "linux.lan"
masters {
127.0.0.1;
};
};
For a DNS server on a closed intranet, drop the root.hints file and the
"." root servers specification in the named.conf file.
To restart the named DNS server...
% ndc reload