Copyright (C) 2005, 2011 by Steve Litt, All rights reserved. Material provided as-is, use at your own risk.
CONTENTS |
OTHER ARTICLES |
NOTE
The preceding paragraph was written in 2005, along with most of this document. Today, in 2011, djbdns is now in the public domain so it's legal to include it with a distribution, and many distros have djbdns packages. And many of those don't work. For what it's worth, here in 2011 I still think it's better to compile your own djbdns. |
dig @192.168.100.2 troubleshooters.comThe preceding asks the DNS server at 192.168.100.2, which happens to be dnscache, the IP of troubleshooters.com. It doesn't matter what's in your /etc/resolv.conf file. It doesn't matter what other DNS servers on the subnet are doing. It pinpoints your dnscache at 192.168.100.2.
dig @127.0.0.1 wincli.domain.cxmIf the preceding succeeds, you can look at /etc/resolv.conf, at your local dnscache server, and whether your local dnscache server has a dnscache/root/servers/domain.cxm containing 127.0.0.1. in order for the dnscache server to query the tinydns server. Any way you look at it, your job has become easier because you know there's nothing wrong with the ability of your authoritative server to serve out local DNS.
Forward lookup (Domain name to IP address) |
|
dig @dnsserverIP domainname |
Reverse lookup (IP address to Domain name) |
dig @dnsserverIP -x IPaddress |
slitt@mydesk:~$ ps ax | grep svscan | grep -v grepWhat happened here is the svscanboot program runs on boot. It runs svscan after setting svscan's default directories, i/o type, environment variables and the like. svscanboot defaults the "service directory" to /service.
1026 ? Ss 0:00 /bin/sh /command/svscanboot
1031 ? S 0:00 svscan /service
slitt@mydesk:~$
ln -s /var/service/dnscache /serviceOnce you do that, on its next loop through /service, the svscan program notices the new dnscache subdirectory, configures a supervise directory in every new subdirectory containing an executable run command, performs some more setup work, and then turns the new service on. Performing that symlink is not a passive action -- there are (desireable) side effects.
In the listing to the right, /service/dnscache is the
directory for service dnscache.
It contains four directories:
The supervise directory is created when you symlink the actual service tree to the /service directory. For instance: ln -s /var/service/tinydns /service/tinydnsIn the preceding, /var/service/tinydns is an actual, physical directory created by you. /service/tinydns is the symlink -- a name refering to /var/service/tinydns. As daemontools loops, it checks the /service tree for any new subdirectories. If it finds one, it looks for an executable named run in that subdirectory, and if found, daemontools creates a properly configured supervise directory. If you look carefully, you'll see a supervise directory inside the log directory. That's because service logging is, by itself, a service, with its own run command. For any directory, the run command typically grabs environment variables from the env directory, then runs exec on the real executable, possibly assigning a different user and group to the execution. Ponder this setup for awhile, and you'll see its brilliant modulatity. You can take any app that runs on the command line, call it in a run command, issue any special variables or state within the env directory, set up any special logging in the run command in the log directory, and you're pretty much done. But there are a few issues... |
|
cd /service/dnscache
rm /service/dnscache
svc -dx . log
24048 ? S 0:00 supervise dnscacheThe following are processes for tinydns:
24058 ? S 0:00 /usr/local/bin/dnscache
3121 ? S 0:00 supervise tinydnsWhile the processes for a service are running, reinstalling that service yields problematic results. If you're lucky they'll be so problematic that the service cannot be started, stopped, or svscan'ed. If you're unlucky, they'll be subtly unnoticable, leaving you open to intermittent problems or even security breaches. Always make sure these processes are not running before trying to reinstall.
3129 ? S 0:00 /usr/local/bin/tinydns
[root@mydesk dnscache]# ls -ldF /service/dnscache/supervise/* |
#!/bin/sh |
svc: warning: unable to control /service/dnscache/: file does not existScuse me? /service/dnscache/ certainly does exist. Could you please be more explicit?
Command |
Action |
|||
svc -u /service/tinydns |
Turn on tinydns. It will turn on
after reboot. |
|||
svc -d /service/tinydns | Turn off tinydns. It will not
turn on after reboot. |
|||
svc -t /service/tinydns |
Restart tinydns if it is on, but
not if it's off. This is used to restart a service after making a
configuration change. |
|||
svc -t /service/* |
Restart all daemons under the
/service directory -- typically both tinydns and dnscache. |
|||
svstat /service/* |
Check the on/off status of all
daemons under the /service directory - typically both tinydns and
dnscache. |
Download source for daemontools, ucspi-tcp and djbdns
Install daemontools
Install ucspi-tcp
Install djbdns
Which consists of:
tinydns: The authoritative resolver
dnscache: The recursive (caching) resolver
Configure dnscache on an alias to the network card
Do not continue until external name resolution works
Configure tinydns on 127.0.0.1
127.0.0.1 is best for SOHO where only subnet clients ask
Link dnscache to tinydns
xproperty1:property2:property3:property4:property5In the preceding, x is a single character that defines the line type, which in turn defines the DNS record types it creates. Each property defines a property of the record(s). Different line types take different numbers of properties, up to 12 for the Z type.
xproperty1::property3The preceding sets property 2 to default, and properties 4 and above (if any) to default values.
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
. |
fqdn | ip | x | ttl | timestamp | lo | |||||
& | fqdn | ip | x | ttl | timestamp | lo | |||||
= | fqdn | ip | ttl | timestamp | lo | ||||||
+ | fqdn | ip | ttl | timestamp | lo | ||||||
@ | fqdn | ip | x | dist | ttl | timestamp | lo | ||||
# | comment | ||||||||||
^ | fqdn | p | ttl | timestamp | lo | ||||||
Z | fqdn | mname | rname | ser | ref | ret | exp | min | ttl | timestamp | lo |
- | fqdn | ip | ttl | timestamp | lo | ||||||
' |
fqdn | s | ttl | timestamp | lo | ||||||
C | fqdn | p | ttl | timestamp | lo | ||||||
% | lo | ipprefix |
. | A line starting with a dot maps to 3 records. This line is
replaced by an SOA record, an
NS record, and an A record. .fqdn:ip:x:ttl:timestamp:lo The SOA is for domain fqdn, with name server name x, time to live ttl, timestamp timestamp, and location lo. The contact email defaults to hostmaster@x (see x for special handling of dots).( The NS record is for domain fqdn, with name server ip address ip, name server name x, time to live ttl, timestamp timestamp, and location lo. The A record associates name server x with ip address ip. If you don't like the defaults for dot lines, substitute line types such as &, Z, = and the like, which map to fewer record types. |
& | Maps to 2 records. This line is replaced by an NS record and
an A record. &fqdn:ip:x:ttl:timestamp:lo The NS record is for domain fqdn, with name server ip address ip and name server name x (see x for special handling of dots). You can also specify ttl, timestamp and lo. |
= | Maps to 2 records. This line is replaced by an A record and a
PTR record. In other words, it defines forward and reverse name
resolution for a specific host. =fqdn:ip:ttl:timestamp:lo Unlike in . and & lines, in = lines fqdn represents a machine, not just a domain. In other words, if the machine is wincli, and the domain is domain.cxm, fqdn would be wincli.domain.cxm. The IP address it maps to is ip. Remember, this mapping is both forward and reverse with this type of line. You can also specify ttl, timestamp and lo. This is a very easy shorthand because it eliminates the need to reverse the IP address and add in-addr.arpa for reverse DNS. |
+ | Maps to 1 record, an A record. This is exactly like an = line except there's no PTR record, so it
doesn't define reverse name DNS. +fqdn:ip:ttl:timestamp:lo |
@ | Maps to 1 record, an MX record. Acts just like = record except it defines a single MX
record. @fqdn:ip:x:dist:ttl:timestamp:lo fqdn, ip, and x all act just like an = record. The dist parameter represents email distance. You can also specify ttl, timestamp and lo. |
# | This line is a comment, so the second field is the text of
the comment. #comment Remember this is visible only in the source. It is not a comment about a domain, visible in DNS. See single quote lines for that. |
^ | Maps to 1 record, a PTR record. ^fqdn:p:ttl:timestamp:lo Here, fqdn is an in-addr.arpa name, like 5.100.168.192.in-addr.arpa, which would represent IP address 192.168.100.5. p is the fully qualified domain of the host, such as wincli.domain.cxm. You can also specify ttl, timestamp and lo. |
Z | This line maps to a single SOA record. Zfqdn:mname:rname:ser:ref:ret:exp:min:ttl:timestamp:lo You would use this instead of a . line if you wanted non-default values for the properties. For instance, the dot line defaults rname to hostmaster@fqdn. Click the links to learn about the rest of the Z line's properties, most of which cannot be specified on a . line. |
- | A line starting with a minus sign maps is exactly like one
starting with a plus sign, except it has been commented out
temporarily. This is used by some automated tinydns config tools. |
' | A line starting with a single quote maps to a single TXT
record. 'fqdn:s:ttl:timestamp:lo Here s is a string containing the desired text. |
C | This line maps to a CNAME record. Cfqdn:p:ttl:timestamp:lo Here fqdn is the fully qualified hostname of the host, while p is the fully qualified host name of the main name you want to point to. The idea is that you can change the IP address of all an IP address's CNAMEs by changing it for the main name. CNAMEs are falling out of favor these days -- so don't use C lines unless you have a good reason to. Instead, use a + instead. |
% |
This line defines a location,
which can be used to specify a location (lo) in
other lines. %lo:ipprefix |
comment | The comment property is the text of a #
line. |
dist | This is the mail exchanger distance, which helps mail
exchanger algorithms decide how best to route a email. |
exp | Expire time, used only in Z lines. |
fqdn | In lines defining an SOA, NS or MX record ( . , &, Z, @) this is the
full domain name of the domain. It does not specify a specific host.
Such a specific host is specified by another property, typically the x or mname properties.
This is true even if the line also defines an individual host as the
name server. In lines that do not define an SOA, NS or MX record, it is
the fully qualified domain name of the host. |
ip | The IP address. For =, + and - lines, it is
the IP of the specific host. For @ lines it's the IP address of the
primary mail exchanger. For . , &, and Z lines it's the IP address of the name server. |
ipprefix |
An IP prefix defining a subnet. For instance, IP prefix 192.168.100 would include 0 through 255 in subnet 192.168.100. IP prefix 192.168 would include subnets 0 through 255 in subnet 192.168. |
lo | Location. Most lines can be restricted to queries coming from
a certain location, where location is typically an IP address range or
a domain or server. If a line has a lo property, that location must
have been created with a % line. |
min | Minimum time, used only in Z lines. |
mname | Primary name server fully qualified domain name (full hostname), used only in Z lines. |
p | This is a property indicating a fully qualified domain name
in a reverse DNS situation, or in a CNAME. Therefore, it's used only in
^ lines and C
lines. |
ref | Refresh time, used only in Z lines. |
ret | Retry time, used only in Z lines. |
rname | Email of the DNS contact person, used only in Z
lines, defaults to hostmaster@domainname (fqdn) in the . line. |
s | A string used to represent the text in a TXT record, this is
used only in a ' line (a singlequote line). |
ser | Serial number, used only in Z lines. |
timestamp | A property marking a time.
If ttl is zero, it represents the time at
which the current line will end (time to die). If ttl
is non-zero or omitted, timestamp represents the time before which the
line will be ignored. This property is expressed in hexidecimal. See the djbdns website for details. |
ttl | Time To Live. The time after which the line "expires" and
must be reloaded by clients, slaves and the like. |
x | This is the hostname of a server. On . , & and Z, if it contains no dots it is prepended to ns.fqdn. On @lines, if it contains no dots it is prepended to mx.fqdn. On all lines, if it contains one or more dots, it is used literally as the name of the name server or mail server. |
[slitt@mydesk djbdns]$ ping www.yahoo.com |
To
test this: |
Do
this: |
Forward resolution using
resolv.conf and dnscache. The question section queries on wincli.domain.cxm, and the answer section delivers 192.168.100.5. Note that just below query time, the server is listed at 192.168.100.103, port 53. This is the IP address of the alias to which I bound dnscache. |
[slitt@mydesk djbdns]$ dig wincli.domain.cxm |
Reverse resolution using
resolv.conf and dnscache The question section queries on 5.100.168.192.in-addr.arpa, which means query the reverse dns for IP address 192.168.100.5, and the answer section delivers wincli.domain.cxm. |
[slitt@mydesk djbdns]$ dig -x 192.168.100.5 |
Forward resolution querying
tinydns directly at 127.0.0.1 Here we're performing the same task as the previous forward resolution, except we're cutting /etc/resolv.conf and dnscache out of the loop by directly querying 127.0.0.1, which is the IP address to which I've bound tinydns. |
[slitt@mydesk djbdns]$ dig @127.0.0.1 wincli.domain.cxm |
Reverse resolution querying
tinydns directly at 127.0.0.1 Once again, we've cut resolv.conf and dnscache out of the loop, for more precision troubleshooting. |
[slitt@mydesk djbdns]$ dig @127.0.0.1 -x 192.168.100.5 |
svc -d directory |
Takes down the service defined
by the directory |
svc -d /service/tinydns takes down tinydns |
svc -u directory | Brings up the service defined by the directory | svc -u /service/tinydns brings up tinydns |
svc -t directory | This sends a term signal to the
service defined by the directory. Normally this would kill the app, but
due to the functionality of daemontools the app starts right back up
again, so this is a restart and is much more convenient than svc -d /dir; svc -u /dir. |
svc -u /service/tinydns takes down tinydns |
tinydns-data |
This reads the data file in the current
directory (meaning you must be in /service/tinydns/root,
and puts it into memory. This must be done any time the data file is
changed, or the changes won't be recognized. After doing this, perform
a svc -t directory to
restart tinydns itself. |
cd /service/tinydns/rootReloads data from data file |
#!/bin/sh |
svstat /service/dnscacheIf svstat says it's up, notice for how long. If it's regularly up for only 0 or 1 seconds, you have the looping restart problem. If it's down, restart it with the svc -t command. If either gives errormessages about can't read file, can't write file, "text busy", look at the supervise directories.
svc -t /service/dnscache
dig @127.0.0.1 myclient.mydoman.mytldIn the preceding, 192.168.100.5 is assumed to be the IP address for myclient.mydomain.mytld. Substitute as necessary. Likely, substitute the fully qualified domain name of one of your hosts for myclient.mydomain.mytld.
dig @127.0.0.1 -x 192.168.100.5
.mydomain.mytld:192.168.1.100 # SOA record for mydomain.mytld |
#!/bin/sh
|
WARNING
Authoritative DNS created from the data.hello file listed above works only at the tinydns IP address, NOT at the dnscache IP address, regardless of how you configure your links. That's because the domain name is different, as is the nameserver address. Therefore, be sure to use the @127.0.0.1 (or whatever IP address is assigned to your tinydns setup) in order to perform this test. |
showdir.sh |
#!/bin/sh
|
look_at_supervise.sh |
#!/bin/sh
|
[root@mydesk root]# ./look_at_supervise.sh dnscache
|