Content:

• Introduction
• Servers
• axfrdns
• dnscache
• rbldns
• tinydns
• walldns
• Client tools
• axfr-get
• dnsfilter
• dnsip
• dnsipq
• dnsname
• dnsq
• dnsqr
• dnstrace
• dnstracesort
• dnstxt
• randomip
• rbldns-data
• tcprules
• tinydns-data
• tinydns-edit
• tinydns-get
• Appendix

Author: Satya K.

Introduction

N-DJBDNS is a brand new release of the DJBDNS.

Years ago, after a chanced conversation with Rahul about DJB, qmail and its peculiarities, Rakesh asked me to package something for Fedora distribution and I said okay. Next day, as I was scrolling down the long list of packages that people wished to see in Fedora, I stumbled upon djbdns. It was for that conversation that I clicked on the link and reached to the source of djbdns. After some reading and browsing about the package, I took upon packaging djbdns for Fedora, completely oblivious to the full measure of the mess I was stepping into.

Soon into the installation and configuration of djbdns, I realised what Rahul meant by peculiar. But it was late to stop then, so I continued with meek reluctance and ended up packaging daemontools along with djbdns. There began a loop of package review-change-review process, at the end of which I cut a deal to set djbdns free from the clutches of daemontools and package again. Thus setting the genesis of the New DJBDNS.

This huge mess of restructuring and renovation aims to:

• Make djbdns as much concise & independent as possible.
• Simplify installation & configuration using GNU auto tools.
• Drop the various *-conf programs.
• Follow FHS conventions for all kinds of configuration, data and log files.
• Write good user manuals and documentation.
• While doing all of this and more, not loose track of security and apply all the patches available so far.

Today, these initial packaging goals are met. Many users have contributed in numerous ways to this progress. Now we look forward to the greater development and growth of N-DJBDNS and its happy users.

DJBDNS

DJBDNS is an implementation of the Domain Name System, originally written by Dr. D J Bernstein. The Domain Name System(DNS) is a database of 'name & address' pairs. Wherein, name is the internet name, aka Domain Name and address is an internet address, aka IP address of a computer(or device). It is a distributed database arranged as a hierarchical tree structure. DNS is often referred to as the 'backbone' or 'core' of the Internet infrastructure. DNS was created in the early '80s to associate human readable names to numerical computer addresses; As remembering and exchanging numerical addresses isn't quite convenient. A plain text file containing these 'name & address' pairs was maintained on the server. When a client asked for an address, the server would read from the text file and provide the address associated with a given name. The rules and language of this client - server communication is known as the DNS specification defined by rfc1034 & rfc1035.

DJBDNS implements this specification in two separate tools; One is the root server and the other is the resolver. The root server called tinydns is used by the DNS zone owners and administrators. It listens on UDP port 53 for incoming requests and when a user request for an address in its zone is received, tinydns answers it by looking into its 'data.cdb' file, which holds a list of 'name & address' pairs. The resolver dnscache on the other hand, is used by all users to do domain name resolution. It too listens on UDP port 53 for incoming requests. When a user request is received, dnscache first contacts one of the root name servers and iteratively to subsequent name servers as directed by the root server. This iteration continues till the given name is resolved or it can not be resolved.

This segregation of the DNS functions into separate tools is intended to make the implementation nimble, robust and more secure. Apart from the root server and a resolver, DJBDNS comes with multiple client side tools. These are extremely handy in debugging and/or diagnostic processes. This document describes all these tools, in details, with their usage, configurations and new features. First we cover the multiple DNS servers and later the client side tools.

axfrdns

axfrdns is a DNS zone transfer server.

axfrdns reads a zone transfer request via DNS-over-TCP method from its standard input and responds with the locally configured zone information. axfrdns looks up for zone transfer results in its 'data.cdb' file; A binary file created using tinydns-data(1). It also responds to normal client queries such as SOA queries, which usually precede zone transfer requests.

axfrdns is invoked via Systemd or Xinetd service managers. Upon invocation, axfrdns reads from its configuration file under '/etc/ndjbdns/' directory. axfrdns allows zone transfer for any zone listed in the $AXFR variable. AXFR is a slash separated list of domain names. If AXFR is not set, axfrdns allows zone transfer for all zones available in its 'data.cdb' file.

dnscache

dnscache is a DNS resolver daemon.

dnscache is used to map a domain name to its IP address and vice versa. Upon invocation, dnscache reads from its configuration file, changes its root directory to $ROOT and listens on TCP/UDP port 53 for incoming requests. Typically dnscache accepts incoming requests from only localhost (ie. 127.0.0.1). To accept requests from external machine or subnet, user needs to create a file, named after an IP address of a machine or subnet from which to accept requests, under the 'ip/' directory. i.e. dnscache would accept requests from IP address 1.2.3.4, if there is a file named 1.2.3.4 OR 1.2.3 OR 1.2 OR 1 under the 'ip/' directory.

To resolve a domain name, dnscache contacts the name servers listed in files under the 'servers/' directory. File 'roots' lists the root name servers. dnscache would contact servers listed in the 'servers/mydomain.com' file, to resolve domain names that end with 'mydomain.com', like say: mail.mydomain.com or irc.mydomain.com etc.

Note: these files list IP addresses of name servers one on each line.

From version 1.05.9, dnscache introduced support for the DNS(or Domain) Block List. DNS Block List is a list of domain names which are to be blocked by the resolver. Client requests querying for such domain names are dropped by the resolver. This would add an additional layer of security for DNS clients and also help reduce malicious traffic.

DNS block list is a 'cdb' database created using tinydns-data(1) tool. List the malicious domain names into a 'data' file as generic domain records, one on each line, as:

    :bad.domain.com:284::::

Number '284' is not used, it can be any number between 256...65535. tinydns-data(1) would create a 'data.cdb' database from this 'data' file. Rename data.cdb to dnsbl.cdb, because that is the file read by dnscache server.

    $ mv data.cdb dnsbl.cdb

dnscache would read 'dnsbl.cdb' from its working($ROOT) directory defined in the 'dnscache.conf' file.

rbldns

rbldns is a Real time Block List DNS server.

rbldns accepts iterative DNS queries from clients seeking information about IP addresses. It provides responses showing whether the addresses are listed on the locally configured Real time Block List(RBL) or Dialup Users List(DUL). When invoked, rbldns reads from the configuration file and listens on UDP port 53 for the incoming requests. When the request is received, rbldns answers it by looking in the 'data.cdb' file placed under the $ROOT directory specified in its configuration file.

tinydns

tinydns is the DNS root server.

tinydns is a DNS root server that answers DNS queries from other hosts with locally configured zone information. When invoked, tinydns reads from its configuration file, changes working directory to $ROOT and listens on UDP port 53 for the incoming requests. When a request is received, tinydns answers it by looking into 'data.cdb' file placed under the $ROOT directory specified in the configuration file.

Until version 1.05.8, tinydns used to read from 'data.cdb' for every request it received and responded to. In version 1.05.9, tinydns was changed to read 'data.cdb' ones at the beginning and later when signalled via SIGUSR1. From version 1.06, it has been further improvised to read 'data.cdb' every 5 seconds. Signal SIGUSR1 is no longer required and so is not processed any more.

walldns

walldns is a reverse DNS wall.

walldns accepts DNS queries for the 'in-addr.arpa' domain on the UDP port 53. Walldns rejects inverse queries, non-internet class queries, truncated packets, packets that contain anything other than a single question, queries for domains outside in-addr.arpa and requests types other than A, PTR, and *.

axfr-get

axfr-get is a DNS zone transfer client.

axfr-get sends a zone transfer request in DNS-over-TCP format to descriptor 7, reads the result from descriptor 6 and saves the result in a file. axfr-get performs the zone transfer for the given domain and writes the result to file OUTFILE.TMP in a format that can be used as input to tinydns-data(1). If the zone transfer completes successfully, axfr-get renames OUTFILE.TMP to OUTFILE.

dnsfilter

dnsfilter converts IP address to host name

dnsfilter does the opposite of dnsip. It sends reverse queries to convert a given IP address to the corresponding host name. When a query returns the host name, dnsfilter prints the result as

     <ip-address>=<host-name>

and in case of any error it goes like

     <ip-address>:<error-message>

dnsip

dnsip resolves domain name

dnsip serves the sole task of resolving a given domain-name to its IPv4 address.

dnsipq

dnsipq is a DNS lookup tool

dnsipq accepts a list of fully qualified domain names, resolves each of them and prints a record of the following form for each domain name.

    <domain-name> <ip-address>

dnsname

dnsname gets name of the DNS server

dnsname is a handy tool to resolve name of the DNS server. You can pass IP address of a DNS server and dnsname would resolve it for you.

dnsq

dnsq query a DNS server

dnsq lets you query a DNS server for specific type of DNS records about a given domain name. Supported record types are listed in the appendix.

dnsqr

dnsqr query DNS record

dnsqr lets you query for specific type of records about a given domain name. Supported record types are listed in the appendix.

dnstrace

dnstracesort

dnstrace is a kind of traceroute(8) for DNS records

dnstrace is a useful debugging tool to search for all DNS servers that can affect the resolution of a record of given type under a give domain name starting from the root name server root ip. dnstrace uses the standard DNS resolution algorithm but follows all possible paths in the algorithm. It prints all responses it receives from the DNS servers. It also prints warnings about slow servers, dead servers, wrongly delegated servers and incorrectly formatted packets.

     $ dnstrace A google.com 127.0.0.1 | dnstrcesort

One can use the dnstracesort in conjunction with the dnstrace. It produces more human friendly sorted output.

dnstxt

dnstxt query DNS TXT record

dnstxt accepts a list of fully qualified domain names, queries and displays TXT records for each of them. Each record is displayed on a separate line.

A TXT record is used to store any human readable text. Lately it has been known to store binary data such as Sender Policy Framework(SPF) details or opportunistic encryption details etc.

randomip

randomip generate random IP addresses

randomip is a simple tool to generate specified number of random IP addresses. By default it generates 10,000 of them. One can specify how many IP addresses to generate followed by the first, second and third byte of the IP address.

rbldns-data

rbldns-data generate data.cdb for rbldns

rbldns-data is used to generate the binary file 'data.cdb', used by rbldns server to answer the user requests. rbldns-data reads the Real time Block List(RBL) or Dialup Users List(DUL) information from a file called 'data' in the current directory and writes a binary file 'data.cdb' in the same directory. One can update 'data.cdb' while rbldns is running. rbldns-data leaves the old .cdb file intact in case if something goes wrong while updating data.cdb.

tcprules

tcprules compile rules for tcpserver

tcprules reads rules from its standard input and writes them into cdb binary format suitable for quick access by tcpserver(1). tcprules can be used while tcpserver(1) is running. It ensures that cdb is updated automatically. It does it by first writing the rules to a temporary file and then writing the temporary file to the cdb. If the temporary file already exists, it is destroyed.

Rule format:

A rule is one line. A file containing rules may also contain comments beginning with '#'. Each rule contains an address, a colon, and a list of instructions, with no extra spaces. When tcpserver(1) receives a connection from that address, it follows the instruction. tcpserver(1) uses the first rule it matches.

tcprules treats 1.2.3.37-43:ins as an abbreviation for the rules 1.2.3.37:ins - 1.2.3.43:ins. Similarly 10.2-3 is an abbreviation for 10.2.:ins and 10.3.:ins.

The instructions in a rule must begin with an allow or deny. deny tells tcpserver(1) to drop the connection without processing any further.

tinydns-data

tinydns-data generate data.cdb for tinydns

tinydns-data is used to generate the binary file 'data.cdb', used by tinydns server to answer the user requests. tinydns-data reads the DNS information from a file 'data' in the current directory and writes a binary file 'data.cdb' in the same directory. One can update 'data.cdb' while tinydns is running. tinydns-data leaves the old .cdb file intact in case if something goes wrong while updating data.cdb.

tinydns-edit

tinydns-edit write DNS records to 'data' file.

tinydns-edit write the DNS records to the 'data' file. tinydns-data uses this 'data' file to generate a binary 'data.cdb'. tinydns or axfrdns servers use the 'data.cdb' file to serve user requests.

tinydns-get

tinydns-get get the tinydns server records

tinydns-get is used to query the tinydns server records from the 'data.cdb' file in the current directory. If an IP is provided, it simulates the results of a query from the given IP address. This matters if 'data.cdb' is different at different client locations.

Appendix

DNS record types

• A: Returns an IPv4 host address for the given domain name.


• ANY: Returns any records that are available for the given domain name.


• NS: Returns an authoritative name server for the given domain name.


• MX: Returns the Mail Exchange for the given domain name.


• PTR: Returns a pointer to another part of the domain name space.


• TXT: Returns a textual representation of the records for the given domain name.


• CNAME: Returns a canonical name of the given domain name or for an alias.


• SOA: Returns the Start of a Zone of Authority.


• HINFO: Returns information such as CPU and OS used by the host.


• RP: Returns a responsible person records for the given domain name.


• SIG: Returns a security signature for the given domain name.


• KEY: Returns a security key for the given domain name.


• AAAA: Returns an IPv6 host address for the given domain name.


• AXFR: Request for a transfer of an entire zone.

Default configuration:

• /etc/ndjbdns/ip/
• /etc/ndjbdns/servers/
• /etc/ndjbdns/axfrdns.conf
• /etc/ndjbdns/dnscache.conf
• /etc/ndjbdns/rbldns.conf
• /etc/ndjbdns/tinydns.conf
• /etc/ndjbdns/walldns.conf

Bugs:

Report bugs via Bugzilla against Product: Fedora, Component: ndjbdns.