Forgot your password?
Document Actions
x204.html
| DNS -- Domain Name Service | ||
|---|---|---|
| <<< Previous | DNS using djbdns | Next >>> |
Installing and Starting Servers
Add DNS Users
One of the reasons that djbdns is more secure than the default installations of BIND is that every server runs with limited privileges. The first step then is to create these users. Assuming that you're going to run all the servers, and have each group of servers with its own user name. These commands will do the minimum necessary to create these users. Delete the ones you're not going to use.
useradd axfrdns -s /bin/false useradd dnscache -s /bin/false useradd dnslog -s /bin/false useradd rbldns -s /bin/false useradd tinydns -s /bin/false |
dnscache -- caching DNS resolver
Select the appropriate IP address for the resolver. Here I'm going to install it on the internal LAN interface where it's accessible by anybody on the internal LAN. For the purposes of this assume that the internal LAN's on the private class C 192.168.253.0/24, and this machine's on 192.168.253.1.
# Create /csoft/etc/dnscache with all necessary files dnscache-conf dnscache dnslog /csoft/etc/dnscache 192.168.253.1 # Tell dnscache to listen on the 192.168.253.0/24 network touch /csoft/etc/dnscache/root/ip/192.168.253 # Svscan will automatically start the daemon within 5 seconds ln -s /csoft/etc/dnscache /service |
Add dnscache Server to /etc/resolv.conf
Now if you put the line ``nameserver 192.168.253.1'' as the first nameserver line in /etc/resolv.conf you should be able to resolve IP addresses using the new dnscache server.
Enable Access to dnscache for Specific Networks
This server will only listen to UDP DNS requests from networks specified by files in the /csoft/etc/dnscache/root/ip directory. The dnscache-conf program creates one for the 127/8 localhost network, and you will have to create files for other valid networks which is what the ``touch'' command does above for the 192.168.253.0/24 private network. We also have files on our LAN here at Celestial for 192.136.111.0/24 and 204.57.163.0/24, our public networks.
Extensions to dnscache
The RPM for dnscache from Celestial is built with a couple of patches from Uwe Ohse's patches to djbdns which allow one to set the OKCLIENT environment variable to allow any client to access dnscache, and to have dnscache listen on multiple IP addresses which can be useful on dual-hosted machines.
To allow dnscache to answer requests from any client add a line to /csoft/etc/dnscache/run at the top of the file:
OKCLIENT=1; export OKCLIENT |
To have dnscache listen on multiple interfaces, use a comma separated list of IP addresses on the dnscache-conf command line (no spaces around the commas), or edit the /csoft/etc/dnscache/env/IP file manually.
Restart dnscache Server
You will need to restart the dnscache server after making any changes in its configuration files. This is done with the command:
svc -du /service/dnscache |
tinydns -- Authoritative DNS Server
The tinydns program is a content server that supplies DNS information only for those zones for which it is authoritative. This is the server to run on the public DNS server IP addresses to service requests for DNS information in the zones for which it's responsible.
Tinydns doesn't do any recursive lookups, so cannot be used in the /etc/resolv.conf file for general resolution.
Internal private domains require their own tinydns server that is accessible only from the private network. It's easy to run ``split-horizon'' DNS on the internal networks since dnscache can look to the private tinydns server for the internal addresses, and the public tinydns server for the public ones.
Select IP Address and Create Servers
Select the appropriate IP address for tinydns servers. There may well be multiple servers on a single host as describe in the Examples section. Each public DNS server IP address requires its own copy of tinydns, and another private tinydns server's necessary to implement split-horizon DNS. I'm going to use a private IP address, 192.168.1.1 in the example below to prevent any potential problems with people doing cut-n-paste from this documentation on real servers. The domain ``example.com'' is used for the same reasons.
The convention we use is that the first public server will run from /csoft/etc/tinydns, and the private in /csoft/etc/tinydns-private. Additional public servers will run in /csoft/etc/tinydnsN where N then number of the server (it doesn't matter what this is so long as it's consistent and unique to that server). When I configure multiple servers this way, I set the secondary servers to share the same data files by linking their root directories to /csoft/etc/tinydnscache/root.
tinydns-conf tinydns dnslog /csoft/etc/tinydns2 $IPADDR rm -f /csoft/etc/tinydns2/root ln -s /csoft/etc/tinydns/root /csoft/etc/tinydns2/root |
Normally there will only be one private server, unless there's a need to have multiple private domains. In this case, it's probably best to have the local private domains responsible for their own files rather than have a centralized location which might be more difficult to maintain. The private server will run on a localhost IP address since it will only be accessed by the dnscache program on that machine.
publicip=192.168.1.1 pubdomain=example.com privateip=127.0.0.3 privdomain=local.example.com # Create /csoft/etc/tinydns with all necessary files tinydns-conf tinydns dnslog /csoft/etc/tinydns $publicip # Tell dnscache where the public info is available echo $publicip > /csoft/etc/dnscache/root/servers/$pubdomain # create private tinydns server tinydns-conf tinydns dnslog /csoft/etc/tinydns-private $privateip # Tell dnscache where the private info is available echo $privateip > /csoft/etc/dnscache/root/servers/$privdomain # Svscan will automatically start the daemons within 5 seconds ln -s /csoft/etc/tinydns /service ln -s /csoft/etc/tinydns-private /service |
Zone Files
The configuration files for djbdns are considerably simpler than those for BIND as well. Small shops that only have to do DNS for a few domains can add hosts with a single line in a file instead of having to update multiple files as required by BIND. See Life with djbdns Simple Setup for some simple examples of the configuration files. I'm going to address this further in the section on maintaining multiple zones below.
Restart tinydns Server
You will need to restart the tinydns servers after making any changes in their configuration files. This is done with the commands:
rbldns -- Realtime Blackhole List DNS Server
The rbldns server is designed to maintain DNS lists of host IP addresses for fast lookup by mail servers, and other clients that permit them to ALLOW or DENY access depending on whether the IP address is in the list. Historically this has been implemeted to limit e-mail abuse groups with tools like Mail Abuse Prevention System MAPS RBL Realtime Blackhole List, MAPS DUL Dialup Users List, and MAPS RSS Relay Spam Stopper
Maintaining an RBL using standard BIND was messy and ineffient as the files tend to be large, and updating took quite a while. The rbldns program simplifies this drastically since it uses a single data file containing IP addresses and CIDR blocks, one per line. The rbldns server is designed to do one thing very efficiently so it doesn't have the overhead associated with a full content server.
The RBL servers are supported through programs like tcp_wrappers, rblsmtpd (part of the ucspi-tcp package), and other programs using the tcp_wrappers libraries (smail-3.2 uses this). The way this works is that an IP address is converted to an RBL entry by reversing the order of the octets, and appending the RBL name Thus 1.2.3.4 -> 4.3.2.1.rbl.celestial.net. in Celestial's local RBL of hosts that have connected to us to send unsolicited e-mail. All lookups that are in the RBL return the same IP address, typically 127.0.0.2.
The /etc/hosts.allow lines we use for the anti-spam RBLs are:
# local RBL, mostly systems that have hit our spam traps
sendmail,smtpd: {RBL}.rbl.celestial.net. : DENY
# MAPS RBL
sendmail,smtpd: {RBL}.rbl.maps.vix.com. : DENY
# MAPS DUL (Dialup Users List)
sendmail,smtpd: {RBL}.dialups.mail-abuse.org. : DENY
# MAPS RSS (Open Relays that have sent spam).
sendmail,smtpd: {RBL}.relays.mail-abuse.org. : DENY
sendmail,smtpd: {RBL}.rbl.xenitec.on.ca. : DENY
sendmail,smtpd: ALL : ALLOW
|
Select IP Address and Create Servers
Each rbldns server needs to run on its own IP address, usually public, and must have corresponding NS entries it its parent domain if it's to be publically accessible.
pubip=192.168.1.2 rbldomain=rbl.example.com rbltxt="Local RBL List" rbldns-conf tinydns dnslog /csoft/etc/rbldns $pubip echo $pubip > /csoft/etc/dnscache/root/servers/$rbldomain # Create IP address and description in file echo ":127.0.0.2:$rbltxt" > /csoft/etc/rbldns/root/data # now create the database gmake -C /csoft/etc/rbldns/root # finally link it to /service so that the daemon will start ln -s /csoft/etc/rbldns /service # restart dnscache so that it will recognize rbldns svc -du /service/dnscache |
axfrdns -- Server for BIND Zone Transfers
The axfrdns program runs on the same IP address as the tinydns server, and uses its data files to provide zone transfers to BIND systems. It listens on the TCP port of the IP address while tinydns listens on the UDP port.
It isn't necessary to run axfrdns if all the name servers for your domains are using dbjdns because they will keep their files synchronized using the rsync program.
Create axfrdns Servers
There will usually be one axfrdns server for each public tinydns server on a system. These can be added at the same time as the tinydns servers or later using these commands:
publicip=192.168.1.1 axfrdns-conf tinydns dnslog /csoft/etc/axfrdns /csoft/etc/tinydns $publicip ln -s /csoft/etc/axfrdns /service |
Edit the axfrdns Configuration File
One file, /csoft/etc/axfrdns/tcp, controls what servers are allowed to do zone transfers from the axfrdns server. Each axfrdns server gets its zone information from a corresponding /csoft/etc/tinydns/root directory.
This will have a line for each host with a list of the zones it can transfer:
# sample line: # 1.2.3.4:allow,AXFR="heaven.af.mil/3.2.1.in-addr.arpa" # 127.:allow,AXFR="celestial.com/111.136.192.in-addr.arpa" 204.122.16.4:allow,AXFR="gasboy.com/l3sys.com" # ... |
Run ``gmake -C /csoft/etc/axfrdns'' after editing this file to build the /csoft/etc/axfrdns/tcp.cdb file.
You can link the /csoft/etc/axfrdns/tcp* files to other multiple axfrdns servers if necessary so that there's only one file to edit for all the axfrdns servers running on a machine.
| <<< Previous | Home | Next >>> |
| Installing Software on Caldera Linux Systems | Up | Maintaining Multiple Domain Files |