NAME
nonamed - not a name daemon, but acts like one
SYNOPSIS
nonamed [-qs] [-d[level]] [-p port]
DESCRIPTION
Nonamed is not a name daemon. It can answer simple queries
from /etc/hosts, but anything else is relayed to a real name
daemon. Nonamed maintaines a small cache of replies it has
seen from a name daemon, and will use this cache to minimize
traffic if the machine is permanently connected to the
Internet, or to answer requests if the machine is often
disconnected from the Internet, i.e. a computer at home.
On startup nonamed sends a simple query to each of its name
servers to see if one is up. This is repeated every five
minutes" in an "at home" situation, or when necessary if the
current name daemon doesn't respond. The first name server
to answer is used as the current name server to answer
queries.
If no name servers are found in the DHCP data or /etc/hosts
then only the hosts file is used to answer queries, and any
query for a name not in that file gets a failure response.
Nonamed accepts both UDP and TCP queries under Minix-vmd.
Under standard MINIX 3 only UDP queries are accepted. 256"
relayed UDP queries can be outstanding before it forgets
where the first one came from.
Using the hosts file, nonamed can answer simple DNS queries
to translate a host name to an IP address, or an IP address
to a host name. Suppose /etc/hosts looks like this:
10.0.0.1 flotsam.cs.vu.nl www
10.0.0.2 jetsam.cs.vu.nl
Then queries for the host names listed can be answered with
the IP addresses to the left of them. An alias like "www"
above is seen as a CNAME for the first host name on the
line, in the same domain as the first host name if unquali-
fied (no dots). A reverse lookup for an IP address on the
left is answered by the first host name on the right. If
more than one match is possible then all matches are put in
the answer, so all IP addresses of multihomed hosts can be
listed by multiple entries in the hosts file.
Requests for names like "flotsam.cs.vu.nl.cs.vu.nl" that are
often generated on a domain search for an already fully
qualified domain name are recognized and made to fail. This
kludge avoids a lot of unnecessary requests to possibly
unreachable name servers and client timeouts.
The name "localhost" in any domain is given the IP address
127.0.0.1.
Nonamed employs several timeouts for efficient operation:
If no UDP reply is seen in four seconds" then a new search
is started for a name server in the hope of finding one that
does work. A failing TCP connection will also invoke a
search, the TCP connection is then made to the new name
server. A client using UDP will retry eventually, a client
using TCP will notice nothing but a short delay. If a TCP
connection fails after 5 tries then an answer is sought in
the hosts file, and failing that the connection is closed.
Any TCP operation is given five minutes" to show any action
before the connection is aborted.
UDP replies from a name server are put in a cache of by
default 8 (16-bit system) or 16 kilobytes (32-bit system).
New queries are first sought in the cache, and if found
answered from the cache. An entry in the cache is expired
when the resource record with the smallest TTL (time to
live) expires, unless its expire time is artificially
extended by the "%stale" parameter (see below). An answer
from the cache has all TTLs appropriately lowered, and the
AA bit ("answer authoritive") is cleared. Any request
answered by stale data is refreshed as soon as nonamed
notices that one of the external name daemons is reachable.
Data is only cached if it is has "no error" result code, or
a "no such domain" result code with a SOA record in the name
server section, and all records have a nonzero TTL. The
%stale parameter has no effect on the decision to cache a
result.
The cache is rewritten to the cache file five minutes" after
a new entry has been added. Mere changes to the order in
the cache don't cause a rewrite.
Configuration through /etc/hosts
The real name servers, stale data extension, and cache size
can be configured by special entries in the hosts file. For
example:
86400 %ttl # Answers from this file get this TTL
2419200 %stale # Stale data may linger on for 4 weeks
32768 %memory # 32k cache size
10.0.0.1 %nameserver # flotsam
172.16.24.3 %nameserver # dns1.example.com
172.16.24.6 %nameserver # dns2.example.com
10.0.0.1 flotsam.home.example.com www
10.0.0.2 jetsam.home.example.com
In this example we have two machines, flotsam and jetsam,
that are at home. Answers from the hosts file get a TTL of
one day, by default this is one hour". Normally there is no
connection to the Internet, so any stale data in the cache
is allowed to linger on for 2419200 seconds (4 weeks) before
it is finally discarded. The cache size is set to 32 kilo-
bytes. The first name server is the flotsam. On the flot-
sam itself this entry is ignored, but the jetsam will now
run its requests through flotsam if possible. This means
that both flotsam and jetsam use the cache of the flotsam.
The other nameserver entries are external name servers of
the Internet provider.
If no nameservers are listed in the hosts file then they are
obtained from data gathered by DHCP. This is the preferred
situation.
If the hosts file contains a line that says:
include file
Then the current hosts file is closed and the file named is
read next.
Automatic calling
If your connection to the Internet is set up on demand,
either in software on the machine that has the modem, or by
a special box such as an ISDN router, then you need to
filter the name server probes that nonamed sends out every
five minutes" to see if a real name daemon is reachable.
These probes need to be recognized as packets that must not
trigger a call, and that must not keep the line up. You can
either filter all IP packets destined for port 53 decimal
(the domain port). This may be a bit too much, the first
packet out is often a normal DNS request (not a probe), so
you may want to do better. A probe by nonamed is a nonre-
cursive request for the name servers of the root domain.
You can recognize them by looking at the flags, they are all
off. Here is a typical probe in hex (twenty octets per
line), followed by the names of interesting fields, and the
octets values you should look for:
45 00 00 2D C8 19 00 00 1D 11 53 18 AC 10 66 41 AC 10 18 03
00 35 00 35 00 19 79 93 00 00 00 00 00 01 00 00 00 00 00 00
00 00 02 00 01
ip ip ip ip ip ip ip ip ip ip ip ip si si si si di di di di
sp sp dp dp xx xx xx xx id id fl fl qd qd an an ns ns ar ar
dn ty ty cl cl
45 xx xx xx xx xx xx xx xx 11 xx xx xx xx xx xx xx xx xx xx
xx xx 00 35 xx xx xx xx xx xx 00 00 xx xx xx xx xx xx xx xx
xx xx xx xx xx
(ip = IP header, si = source IP, di = dest IP, sp =
source port, dp = dest port, id = DNS ID, fl = DNS
flags, qd = query count, an = answer count, ns =
nameserver count, ar = additional records count, dn =
domain (""), ty = type (NS), cl = class (IN).)
So if a packet has octets 45, 11, 00 35, and 00 00 at the
appropriate places then don't let it cause a call. Read the
documentation of your software/router to find out how to do
this. Hopefully it is possible to view the contents of the
packet that triggered the last call. If so you simply let
nonamed bring up the line once with a probe.
Remote information
The program version and name servers it is working with can
be obtained with:
host -r -v -c chaos -t txt version.bind. server
Server is the name or IP address of the host whose name
server you want to know this of. (This call is really an
undocumented hack to ask the version numbers of the BIND
name daemon. It just had to be implemented for nonamed as
well.)
The % variables in the hosts file can be viewed like this:
host -r -t a %nameserver. server
Don't forget the dot at the end of the name. %ttl and
%stale will be shown as a dotted quad, e.g. 0.36.234.0. The
proper value can be computed as 36 * 65536 + 234 * 256 + 0 =
2419200.
OPTIONS
The options are only useful when debugging nonamed, although
it can be very instructive to watch DNS queries being done.
-d[level]
Set debugging level to level (by default 1.) Debug
mode 1 makes nonamed decode and display the DNS queries
and replies that it receives, sends and relays. In
debug mode 2 it prints tracing information about the
internal jobs it executes. In debug mode 3 it core
dumps when an error causes it to exit. The debugging
level may also be increased by 1 at runtime by sending
signal SIGUSR1 or turned off (set to 0) with SIGUSR2.
[-p port]
Port to listen on instead of the normal domain port.
[-q] Read the cache file with the debug level set to 2,
causing its contents to be printed, then exit.
[-s] Run single: ignore hosts or cache file, only use the
DHCP information. This allows another nonamed to be
run on a different interface to serve a few programs
that run there.
FILES
/etc/hosts Hosts to address translation table and confi-
guration file.
/usr/run/nonamed.pid
Process ID of the currently running nonamed.
/usr/adm/nonamed.cache
Copy of the cache. Read when the program
starts, written five minutes" after something
has been added to it, and written when a
SIGTERM signal is received, which is normally
sent at system shutdown.
/usr/adm/dhcp.cache
Data gathered by the DHCP daemon. Among lots
of other junk it lists name servers that we
should use.
SEE ALSO
gethostbyname(3), resolver(3), hosts(5), inet(8), boot(8),
inetd(8), dhcpd(8).
RFC-1034 and RFC-1035.
NOTES
Do not use the %stale parameter for a PC that is directly
connected to the Internet. You run the risk of getting
wrong answers, a risk that is only worth taking for a system
that is mostly disconnected from the Internet.
You can specify one or more remote name servers in
/etc/resolv.conf so that nonamed isn't needed. This will
save memory, but you'll lose nonamed's cache and its "off-
line" tricks. That's no problem if you can use a neighbour-
ing name daemon on another PC at home.
The default cache size seems to be more than enough for nor-
mal use, but if you do decide to make it larger then don't
forget to increase the stack size of the program under stan-
dard MINIX 3.
Don't let two nonamed's forward queries to each other. They
will pingpong a query over the network as fast as they can.
BUGS
The idea of serving "stale DNS data" will probably make some
purists violently sick...
AUTHOR
Kees J. Bot (kjb@cs.vu.nl)