maradns


 

Index

NAME
SYNOPSIS
DESCRIPTION
USAGE
FIREWALL CONFIGURATION
BUGS
UNIMPLEMENTED FEATURES
LEGAL DISCLAIMER
AUTHOR

Section: MaraDNS reference (8)
Updated: November 2001

Erre con erre cigarro
Erre con erre barril
Rápido ruedan los carros
En el ferrocarril
 

NAME

maradns - DNS server  

SYNOPSIS

maradns [ -v | -f mararc_file_location ] >> /var/log/maradns &
 

DESCRIPTION

maradns is a DNS server written with security, simplicity, and performance in mind.

maradns accepts only one of two optional arguments.

The first is the location of a mararc file which MaraDNS obtains all her comfiguration information from. The default location of this file is /usr/local/etc/mararc This is specified in the form maradns -f mararc_file_location where mararc_file_location is the location of the mararc file

The second option is to have MaraDNS display the version number then exit. This is specified in the form maradns -v or maradns --version

 

USAGE

If MaraDNS is functioning only as a recursive nameserver, just one file needs to be set up: The mararc file.

In order for MaraDNS to function as an authoritative nameserver, two or more files need to be set up: the mararc file and one or more "csv1" zone files.

The configuration formation of a csv1 zone file can be obtained from the csv1 (5) manual page. The configuration format of the mararc file can be obtained from the mararc(5) manual page.

 

FIREWALL CONFIGURATION

If MaraDNS is being used as an authoritative nameserver, allow UDP connections from all hosts on the internet to UDP port 53 for the IP that the authoritative nameserver uses.

If MaraDNS is being used as a recursive nameserver, the firewall needs to allow the following packets to go to and from the IP the recursive nameserver uses:

MaraDNS uses a strong secure RNG for both the query (16 bits of entropy) and the source port of the query (12 bits of entropy). This makes spoofing replies to a MaraDNS server more difficult, since the attacker has only a one in 250 million chance that a given spoofed reply will be considered valid.

 

BUGS

When a resolver asks for an A record, and the A record is a CNAME which points to a list of IPs, MaraDNS' recursive resolver only returns the first IP listed along with the CNAME.

When a resolver asks for an A record, and the A record is a CNAME that points to another CNAME (and possibly a longer CNAME chain), while MaraDNS returns the correct IP (as long as the glueless level is not exceeded), MaraDNS will incorrectly state that the first CNAME in the chain directly points to the IP.

If a NS record points to a list of IPs, and the NS record in quesiton is a "glueless" record (MaraDNS had to go back to the root servers to find out the IP of the machine in question), MaraDNS' recursive resolver only uses the first listed IP as a name server.

When MaraDNS' recursive resolver recives a "host not there" reply, instead of using the SOA minimum of the "host not there" reply as the TTL (Look at RFC1034 §4.3.4), MaraDNS uses the TTL of the SOA reply.

MaraDNS keeps referral NS records in the cache for one day instead of the TTL specified by the remote server.

MaraDNS has very limited support for DNS data over TCP. In particular, MaraDNS only uses DNS-over-TCP for zone transfers, which is handled by the companion program zoneserver (see zoneserver(8) for usage information), and only allows authorized IPs to make zone transfer requests.

MaraDNS handles the "any record" (255) request by only returning A and MX records (optionally: NS and SOA records), instead of sending all of the records assosciated with a given host name. The only places where I have seen the "any record" query used is by MTAs, and by the .au and .de registrars. In recursive mode, a request for "any record" is translated in to separate A and MX requests, which MaraDNS subsequently concatenates together.

MaraDNS never returns a NXDOMAIN (nothing in the answer section, SOA in the authority section, result code of "name error" [3]). If a given domain node label does not exist for any RR, MaraDNS will still return a "no host" (nothing in the answer section, SOA in the authority section, 0 result code), implying that the host name exists for at least one RR type.

If a wildcard MX record exists in the form "*.example.com", and there is an A record for "www.example.com", but no MX record for "www.example.com", the correct behavior (based on RFC1034 §4.3.3) is to return "no host" (nothing in the answer section, SOA in the authority section, 0 result code) for a MX request to "www.example.com". Instead, MaraDNS returns the MX record attached to "*.example.com".

Star records (what RFC1034 calls "wildcards") can not be attached to NS records.

MaraDNS' recursive resolver stops resolving when it finds an answer in the AR section. This is a problem in the case where a given host name and IP is registered with the root name servers, and the registered IP is out of date. When this happens, a server "closer" to the root server will give an out-of-date IP, even though the authoritative DNS servers for the host in question have the correct IP. Note that resolving this will result in increased DNS traffic.

MaraDNS, like every other known DNS implementation, only supports a QDCOUNT of 0 or 1.

 

UNIMPLEMENTED FEATURES

These are features which will not be implemented in the 1.0 release of MaraDNS:

MaraDNS does not become a daemon. One can use a shell with job control functionality to make MaraDNS a daemon process, e.g:

nohup maradns > /dev/null &

MaraDNS does not use syslog or any other logging facility to log messages that MaraDNS generates. Instead, the messages are logged to standard output. One can use a shell's output redirection to log messages to a file, e.g:

touch /var/log/maradns
nohup maradns >> /var/log/maradns &

MaraDNS does not have support for a "default" zone, which would allow one to add zones without needing to change MaraDNS configuration files.

MaraDNS, like every other known DNS server implementation, does not have SQL support.

MaraDNS does not have support for allowing given host names to only resolve for a limited range of IPs querying the DNS server, or for host names to resolve differently, depending on the IP querying the host name.

MaraDNS does not support IPv6.

MaraDNS has no signal handlers. Sending a HUP signal to MaraDNS terminates the MaraDNS process instead of telling MaraDNS to reload the configuration files.

With the exception of the ability to decompress some RR types not present in RFC1035, MaraDNS does not support any DNS features which are not present in RFC1034 and RFC1035.

MaraDNS, in accordance with RFC1035 §4.3.3, only allows wildcards at the beginning of a host name. E.g. names with wildcards like "foo.*.example.com" or "www.*" will not work.

 

LEGAL DISCLAIMER

THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

 

AUTHOR

Sam Trenholme http://www.samiam.org/