 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 ]

                          TABLE OF CONTENTS

   This man page has the following sections:

 Name
 Synopsis
 Table of Contents
 Description
 Usage
 Firewall Configuration
 Frequently Asked Questions
 Bugs
 Unimplemented Features
 Legal Disclaimer
 Authors

                             DESCRIPTION

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

   maradns has two forms of arguments, both of which are optional.

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

   It is also possible to have MaraDNS display the version number
   and exit. This is specified by invoking maradns 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.

   In order to have MaraDNS run as a daemon, the duende program is
   used to daemonize MaraDNS. See the duende(8) manual page for
   details.

                        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:

     * Allow UDP connections from the MaraDNS-running server to any
       machine on the internet where the UDP destination port is 53
     * Allow UDP connections from any machine on the internet to
       the IP of the recursive server, where the source port from
       the remote server is 53, and the destination port is between
       15000 and 19095 (inclusive)
     * Allow UDP connections from IPs that use MaraDNS as a
       recursive DNS server to port 53 of the MaraDNS server

   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.

                      FREQUENTLY ASKED QUESTIONS

INDEX

     1. I'm still using version 1.0 of MaraDNS

     2. How do I try out MaraDNS?

     3. What license is MaraDNS released under?

     4. How do I report bugs in MaraDNS?

     5. Some of the postings to the mailing list do not talk
     about MaraDNS!

     6. How do I get off the mailing list?

     7. How do I set up reverse DNS on MaraDNS?

     8. I am on a slow network, and MaraDNS can not process
     recursive queries

     9. When I try to run MaraDNS, I get a cryptic error
     message.

     10. After I start MaraDNS, I can not see the process when
     I run netstat -na

     11. What string library does MaraDNS use?

     12. Why does MaraDNS use a multi-threaded model?

     13. I feel that XXX feature should be added to MaraDNS

     14. I feel that MaraDNS should use another documentation
     format

     15. Is there any process I need to follow to add a patch
     to MaraDNS?

     16. Can MaraDNS act as a primary nameserver?

     17. Can MaraDNS act as a secondary nameserver?

     18. What is the difference between an authoritative and a
     recursive DNS server?

     19. The getzone client isn't allowing me to add certain
     hostnames to my zone

     20. Is MaraDNS portable?

     21. Can I use MaraDNS in Windows?

     22. MaraDNS freezes up after being used for a while

     23. What kind of Python integration does MaraDNS have

     24. Doesn't "kvar" mean "four" in Esperanto?

     25. How scalable is MaraDNS?

     26. I am having problems setting upstream_servers

     27. Why doesn't the MaraDNS.org web page validate?

     28. How do MX records work?

     29. Does MaraDNS have support for SPF?

     30. I'm having problems resolving CNAMES I have set up.

     31. I have a NS delegation, and MaraDNS is doing strange
     things.

     32. I am transferring a zone from another server, but the
     NS records are these strange "synth-ip" records.

     33. Where is the root.hints file?

     34. Are there any plans to use autoconf to build MaraDNS?

     35. How do I change the compiler or compile-time flags
     with MaraDNS' build process?

     36. Will you make a package for the particular Linux
     distribution I am using?

     37. I am using the native Windows port of MaraDNS, and
     some features are not working.

     38. MaraDNS isn't starting up

     39. You make a lot of releases of MaraDNS; at our ISP/IT
     department, updating software is non-trivial.

ANSWERS

1. I'm still using version 1.0 of MaraDNS

   MaraDNS 1.0 will continue to be supported until December 21,
   2007; this means that MaraDNS 1.0 bug fixes will still be
   applied. After 2007/12/21, MaraDNS 1.0 will no longer be fully
   supported; the only updates, at that point, would be
   bugtraq-worthy critical security fixes. Not even these security
   updates will be applied after December 21, 2010.

   People who wish to run MaraDNS 1.0 unsupported after 2010/12/21
   need to keep in mind that MaraDNS 1.0 is not Y2038 compliant,
   and will have problems starting in 2036 or so. MaraDNS 1.2, on
   the other hand, is fully Y2038 compliant.

   There is still a FAQ for version 1.0 of MaraDNS available
   here.

   Updating from 1.0 to 1.2 requires a minimum number of changes;
   with most configurations, MaraDNS 1.2 is fully compatible with
   MaraDNS 1.0 data files. Details are in the updating document
   in the tutorial.

   While csv1 zone files are fully supported in MaraDNS 1.2, there
   is a Perl script for updating from CSV1 to CSV2 zone files in
   the tools/ directory of MaraDNS 1.2.

2. How do I try out MaraDNS?

   Read the quick start guide, which is the file named
   0QuickStart in the MaraDNS distribution.

3. What license is MaraDNS released under?

   MaraDNS 1.2 is released with the following two-clause BSD-type
   license:

     Copyright (c) 2002-2007 Sam Trenholme

     TERMS

     Redistribution and use in source and binary forms, with or
     without modification, are permitted provided that the
     following conditions are met:

     1. Redistributions of source code must retain the above
     copyright notice, this list of conditions and the following
     disclaimer.

     2. Redistributions in binary form must reproduce the above
     copyright notice, this list of conditions and the following
     disclaimer in the documentation and/or other materials
     provided with the distribution.

     This software is provided 'as is' with no guarantees of
     correctness or fitness for purpose.

4. How do I report bugs in MaraDNS?

   Please contact me; my email address is at
   http://www.maradns.org/contact.html. Please be sure to
   include all information requested there, including the operating
   system you are using, the version of MaraDNS you are using, your
   mararc configuration file, and all relevant zone files.

5. Some of the postings to the mailing list do not talk about MaraDNS!

   In cases where I post something to the mailing list which does
   not directly talk about MaraDNS, the subject line will not have
   [MARA] in it, but will have some form of the word CHATTER in it.

   This way, people who do not like this can set up mail filters to
   filter out anything that comes from this list and doesn't have
   [MARA] in the subject line, or simply unsubscribe from the list
   and read the list from the archives; if one needs to report a
   bug, they can subscribe to the list again, post their bug, then
   unsubscribe after a week.

   Another option is to set up one's Freshmeat preferences to be
   notified in email every time I update MaraDNS at Freshmeat. This
   will give one email notice of any critical bug fixes without
   needing to be subscribed to the mailing list.

   The web page http://www.maradns.org/ has a link to the
   mailing list archives.

6. How do I get off the mailing list?

   Send an email to list-request@maradns.org with "unsubscribe" as
   the subject line.

7. How do I set up reverse DNS on MaraDNS?

   Reverse DNS (sometimes called "reverse mapping") is set up by
   using PTR (pointer) records. For example, the PTR record which
   performs the reverse DNS lookup for the ip 10.2.3.4 looks like
   this in a CSV2 zone file:

     4.3.2.10.in-addr.arpa. PTR www.example.com. ~

   It is also possible, on MaraDNS 1.2.05 and more recent releases,
   to use a special "FQDN4" which automatically sets up the reverse
   mapping of a given record:

     www.example.com. FQDN6 10.2.3.4 ~

   If you wish to have a PTR (reverse DNS lookup; getting a DNS
   name from a numeric IP) record work on the internet at large, it
   is not a simple matter of just adding a record like this to a
   MaraDNS zonefile. One also needs control of the appropriate
   in-addr.arpa. domain.

   While it can make logical sense to contact the IP 10.11.12.13
   when trying to get the reverse DNS lookup (fully qualified
   domain name) for a given IP, DNS servers don't do this. DNS
   server, instead, contact the root DNS servers for a given
   in-addr.arpa name to get the reverse DNS lookup, just like they
   do with any other record type.

   When an internet service provider is given a block of IPs, they
   are also given control of the DNS zones which allow them to
   control reverse DNS lookups for those IPs. While it is possible
   to obtain a domain and run a DNS server without the knowledge or
   intervention of an ISP, being able to control reverse DNS
   lookups for those IPs requires ISP intervention.

8. I am on a slow network, and MaraDNS can not process recursive
queries

   MaraDNS, by default, only waits two seconds for a reply from a
   remote DNS server. This default can be increased by adding a
   line like this in the mararc file:

 timeout_seconds = 5

   Note that making this too high will slow MaraDNS down when DNS
   servers are down, which is, alas, all too common on today's
   internet.

9. When I try to run MaraDNS, I get a cryptic error message.

   There is usually some context of where there is a syntax error
   in a data file before the cryptic error message. For example,
   when there is a syntax error in a csv2 zone file, MaraDNS will
   tell you exactly at what point it had to terminate parsing of
   the zone file.

   If MaraDNS does return a cryptic error message without letting
   you know what is wrong, let me know so that I can fix the
   bug. MaraDNS is designed to be easy to use; cryptic error
   messages go against this spirit.

10. After I start MaraDNS, I can not see the process when I run
netstat -na

   Udp services do not have a prominent "LISTEN" when netstat is
   run.

   When MaraDNS is up, the relevant line in the netstat output
   looks like this: udp 0 0 127.0.0.1:53 0.0.0.0:*

   While on the topic of netstat, if you run netstat -nap as root
   on Linux and some other *nix operating systems, you can see the
   names of the processes which are providing internet services.

11. What string library does MaraDNS use?

   MaraDNS uses its own string library, which is called the
   "js_string" library. Man pages for most of the functions in the
   js_string library are in the folder doc/man of the MaraDNS
   distribution

12. Why does MaraDNS use a multi-threaded model?

   The multi-threaded model is, plain and simple, the simplest way
   to write a functioning recursive DNS server. There is a reason
   why MaraDNS, pdnsd, and BIND 9 all use the multi-threaded model.

   I am planning on improving MaraDNS' threaded model to not spawn
   a thread for each and every uncached request.

13. I feel that XXX feature should be added to MaraDNS

   The only thing that will convince me to implement a given
   feature for MaraDNS is cold, hard cash. If you want me to keep a
   given feature proprietary, you better have lots of cold hard
   cash. If you're willing to opensource your feature, less cash
   should be sufficient.

   Keep in mind that both the BIND and NSD name servers were
   developed by having the programmers paid to work on the
   programs. PowerDNS was originally commercial software with the
   author only reluctantly made GPL after seeing that the market
   for a commercial DNS server is very small. All of the other DNS
   servers which have been developed as hobbyist projects (Posadis,
   Pdnsd, and djbdns) are no longer being actively worked on by the
   primary developer.

   My current plans for MaraDNS are visible on the roadmap page
   for MaraDNS.

   If I see a large MaraDNS community and a strong demand for new
   features from that community, I will consider their wishes.
   Especially if some of the members of the community have large
   bank accounts. Should ipv6 start to become dominant, I will
   update MaraDNS to have full ipv6 support. Should some other
   technology come along that will require an update to MaraDNS for
   MaraDNS to continue to function as a DNS server, I may very well
   update MaraDNS to use that technology.

14. I feel that MaraDNS should use another documentation format

   The reason that MaraDNS uses its own documentation format is to
   satisfy both the needs of translators to have a unified document
   format and my own need to use a documentation format that is
   simple enough to be readily understood and which I can add
   features on an as needed basis.

   The documentation format is essentially simplified HTML with
   some special tags added to meet MaraDNS' special needs.

   This gives me more flexibility to adapt the documentation format
   to changing needs. For example, when someone pointed out that
   it's not a good idea to have man pages with hi-bit characters,
   it was a simple matter to add a new HIBIT tag which allows man
   pages to be without hi-bit characters, and other document
   formats to retain hi-bit characters.

   Having a given program have its own documentation format is not
   without precedent; Perl uses its own "pod" documentation format.

15. Is there any process I need to follow to add a patch to MaraDNS?

   Yes.

   Here is the procedure for making a proper patch:

     * Enter the directory that the file is in, for example
       maradns-1.2.00/server
     * Copy over the file that you wish to modify to another file
       name. For example: cp MaraDNS.c MaraDNS.c.orig
     * Edit the file in question, e.g: vi MaraDNS.c
     * After editing, do something like this:
       diff -u MaraDNS.c.orig MaraDNS.c > maradns.patch
     * Make sure the modified version compiles cleanly

   Send a patch to me in email, along with a statement that you
   place the contents of the patch under MaraDNS' BSD license. If I
   find that the patch works well, I will integrate it in to
   MaraDNS.

16. Can MaraDNS act as a primary nameserver?

   Yes.

   The zoneserver program serves zones so that other DNS servers
   can be secondaries for zones which MaraDNS serves. This is a
   separate program from the maradns server, which processes both
   authoritative and recursive UDP DNS queries.

   See the DNS master document in the MaraDNS tutorial for
   details.

17. Can MaraDNS act as a secondary nameserver?

   Yes.

   Please read the DNS slave document, which is part of the
   MaraDNS tutorial.

18. What is the difference between an authoritative and a recursive
DNS server?

   A recursive DNS server is a DNS server that is able to contact
   other DNS servers in order to resolve a given domain name label.
   This is the kind of DNS server one points to in
   /etc/resolve.conf

   An authoritative DNS server is a DNS server that a recursive
   server contacts in order to find out the answer to a given DNS
   query.

19. The fetchzone client isn't allowing me to add certain hostnames to
my zone

   For security reasons, MaraDNS' fetchzone client does not add
   records which are not part of the zone in question. For example,
   if someone has a zone for example.com, and this record in the
   zone:

   1.1.1.10.in-addr.arpa. PTR dns.example.com.

   MaraDNS will not add the record, since the record is
   out-of-bailiwick. In other words, it is a host name that does
   not end in .example.com.

   There are two workarounds for this issue:

     * Create a zone file for 1.1.10.in-addr.arpa., and put the PTR
       records there.
     * Use rcp, rsync, or another method to copy over the zone
       files in question.

20. Is MaraDNS portable?

   MaraDNS is developed on a CentOS 3 and Windows XP dual boot
   laptop. MaraDNS may compile or run on other systems--there are
   official MaraDNS ports for Debian/Ubuntu, Slackware, FreeBSD,
   and NetBSD. Note that MaraDNS needs a system with a robust
   threading library, which some systems do not have.

21. Can I use MaraDNS in Windows?

   Yes. There is both a partial mingw32 (native win32 binary) port
   and a full Cygwin port of MaraDNS; both of these ports are part
   of the native build of MaraDNS.

22. MaraDNS freezes up after being used for a while

   If you are using MaraDNS 1.2.03.1 (or any 1.1 release, for that
   matter) on Linux, upgrade to version 1.2.03.2. There is a bug
   with the Linux kernel which causes UDP clients to freeze unless
   code is written to work around the kernel bug. This workaround
   was first introduced in MaraDNS 1.0.28 and 1.1.35 and accidently
   disabled in 1.2.03.1.

   If using your ISP's name servers or some other name servers
   which are not, in fact, root name servers, please make sure that
   you are using the upstream_servers dictionary variable instead
   of the root_servers dictionary variable.

   If you still see MaraDNS freeze up after making this correction,
   please send a bug report to the mailing list.

23. What kind of Python integration does MaraDNS have

   The mararc file uses the same syntax that Python uses; in fact,
   Python can parse a properly formatted mararc file.

   There is currently no other integration with Python.

24. Doesn't "kvar" mean "four" in Esperanto?

   Indeed, it does. However the use of "kvar" in the MaraDNS source
   code only coincidentally is an Esperanto word. "kvar" is short
   for "Kiwi variable"; a lot of the parsing code comes from the
   code used in the Kiwi spam filter project.

25. How scalable is MaraDNS?

   MaraDNS is optimized for serving a small number of domains as
   quickly as possible. That said, MaraDNS is remarkably efficnent
   for serving a large number of domains, as long as the server
   MaraDNS is on has the memory to fit all of the domains, and as
   long as the startup time for loading a large number of domains
   can be worked around.

   The "big-O" or "theta" growth rates for various MaraDNS
   functions are as follows, where N is the number of authoritative
   host names being served:

 Startup time                            N
 Memory usage                            N
 Processing incoming DNS requests        1

   As can be seen, MaraDNS will process 1 or 100000 domains in the
   same amount of time, once the domain names are loaded in to
   memory.

26. I am having problems setting upstream_servers

   The upstream_servers mararc variable is set thusly:

     upstream_servers["."] = "10.3.28.79, 10.2.19.83"

   Note the ["."]. The reason for this is so future versions of
   MaraDNS may have more fine-grained control over the
   upstream_servers and root_servers values.

   Note that the upstream_servers variable needs to be initialized
   before being used via upstream_servers = {} (the reason for this
   is so that a mararc file has 100% Python-compatible syntax). A
   complete mararc file that uses upstream_servers may look like
   this:

 ipv4_bind_addresses = "127.0.0.1"
 chroot_dir = "/etc/maradns"
 recursive_acl = "127.0.0.1/8"
 upstream_servers = {}
 upstream_servers["."] = "10.1.2.3, 10.2.4.6"

27. Why doesn't the MaraDNS.org web page validate?

   HTML pages on the MaraDNS.org web site should validate as HTML
   4.0 Transitional. However, the CSS will not validate.

   I have designed MaraDNS' web page to be usable and as attractive
   as possible in any major browser released in the last ten years.
   Cross-browser support is more important than strict W3
   validation. The reason why the CSS does not validate is because
   I need a way to make sure there is always a scrollbar on the web
   page, even if the content is not big enough to merit one; this
   is to avoid the content jumping from page to page. There is no
   standard CSS tag that lets me do this. I'm using a non-standard
   tag to enable this in Gecko (Firefox's rendering engine); this
   is enabled by default in Trident (Internet Explorer's rendering
   engine). The standards are deficient and blind adherence to them
   would result in an inferior web site.

   There are also two validation warnings generated by
   redefinitions which are needed as part of the CSS filters used
   to make the site attractive on older browsers with limited CSS
   support.

   On a related note, the reason why I use tables instead of CSS
   for some of the layout is because Microsoft Internet Explorer 6
   and other browsers do not have support for the max-width CSS
   property. Without this property, the web page will not scale
   down correctly without using tables. Additionally, tables allow
   a reasonably attractive header in browsers without CSS support.

28. How do MX records work?

   How MX records work:

     * The mail transport agent (Sendmail, Postfix, Qmail, MS
       Exchange, etc.) looks up the MX record for the domain
     * For each of the records returned, the MTA (mail transport
       agent) looks up the IP for the names.
     * It will choose, at random, any of the MXes with the lowest
       priority number.
     * Should that server fail, it will try another server with the
       same priority number.
     * Should all MX records with a given priority number fail, the
       MTA will try sending email to any of the MX records with the
       second-lowest priority value.

   As an aside, do not have MX records point to CNAMEs.

29. Does MaraDNS have support for SPF?

   SPF, or sender policy framework, is method of using DNS that
   makes it more difficult to forge email. MaraDNS has full support
   for SPF, both via TXT records and, starting with MaraDNS 1.2.08,
   via RFC4408 SPF records.

   SPF configuration is beyond the scope of MaraDNS' documentation.
   However, at the time of this FAQ entry being written (June,
   2006), information and documentation concerning SPF is available
   at http://openspf.org. The BIND examples will work in
   MaraDNS csv2 zone files as long as the double quotes (") are
   replaced by single quotes ('). For example, a SPF TXT record
   that looks like example.net. IN TXT "v=spf1 +mx
   a:colo.example.com/28 -all" in a BIND zone file will look like
   example.net. TXT 'v=spf1 +mx a:colo.example.com/28 -all' in a
   MaraDNS zone file. MaraDNS version 1.2.08 and higher can also
   make the corresponding SPF record, which will have the syntax
   example.net. SPF 'v=spf1 +mx a:colo.example.com/28 -all'.

30. I'm having problems resolving CNAMES I have set up.

   This is probably because you have set up what MaraDNS calls a
   dangling CNAME record.

   Let us suppose we have a CNAME record without an A record in the
   local DNS server's database, such as:

         google.example.com. CNAME www.google.com. ~

   This record, which is a CNAME record for "google.example.com",
   points to "www.google.com". Some DNS servers will recursively
   look up www.google.com, and render the above record like this:

         google.example.com. CNAME www.google.com. ~
         www.google.com. CNAME 66.102.7.104 ~

   For security reasons, MaraDNS doesn't do this. Instead, MaraDNS
   will simply output:

         google.example.com. CNAME www.google.com. ~

   Some stub resolvers will be unable to resolve google.example.com
   as a consequence.

   If you set up MaraDNS to resolve CNAMEs thusly, you will get a
   warning in your logs about having a dangling CNAME record.

   If you want to remove these warnings, add the following to your
   mararc file:

         no_cname_warnings = 1

   Information about how to get MaraDNS to resolve dangling CNAME
   records is in the tutorial file dangling.html

I have a NS delegation, and MaraDNS is doing strange things.

   In the case of there being a NS delegation, MaraDNS handles
   recursive queries and non-recursive DNS queries differently.
   Basically, unless you use askmara with the -n option, dig with
   the +norecuse option, or nslookup with the -norec option,
   MaraDNS will try to recursively resolve the record that is
   delegated.

   The thinking is this: A normal recursive DNS query is usually
   one where one wants to know the final DNS output. So, if MaraDNS
   delegates a given record to another DNS server, and gets a
   recursive request for said query, MaraDNS will recursively
   resolve the query for you.

   For example, let us suppose we have a mararc file that looks
   like this:

 chroot_dir = "/etc/maradns"
 ipv4_bind_addresses = "10.1.2.3"
 chroot_dir = "/etc/maradns"
 recursive_acl = "127.0.0.1/8, 10.0.0.0/8"
 csv2 = {}
 csv2["example.com."] = "db.example.com"

   And a db.example.com file that looks like this:

 www.example.com.        10.1.2.3 ~
 joe.example.com.        NS ns.joe.example.com. ~
 ns.joe.example.com.     A 10.1.2.4 ~

   Next, you are trying to find out why www.joe.example.com is not
   resolving. If you naively send a query to 10.1.2.3 for
   www.joe.example.com as askmara Awww.joe.example.com. 10.1.2.3 or
   as dig @10.1.2.3 www.joe.example.com. or as nslookup
   www.joe.example.com. 10.1.2.3, you will not get any information
   that will help you solve the problem, since 10.1.2.3 will try to
   contact 10.1.2.4 to resolve www.joe.example.com.

   The solution is to run your DNS query client thusly:

     * Askmara would be run thusly:

       askmara -n Awww.joe.example.com. 10.1.2.3

     * Dig would be run thusly:

       dig +norecurse @10.1.2.3 www.joe.example.com

     * Nslookup would be run thusly:

       nslookup -norec www.joe.example.com 10.1.2.3

   This will allow you to see that packets MaraDNS actually sends
   to a recursive DNS server.

   As an aside, this particular problem will not happen if MaraDNS
   is run only as an authoritative nameserver.

I am transferring a zone from another server, but the NS records are
these strange "synth-ip" records.

   MaraDNS expects, in csv2 zone files, for all delegation NS
   records to be between the SOA record and the first non-NS
   record.

   If a zone looks like this:

 example.net. +600 soa ns1.example.net. hostmaster@example.net
 10 10800 3600 604800 1080 ~
 example.net. +600 mx 10 mail.example.net. ~
 example.net. +600 a 10.2.3.5 ~
 example.net. +600 ns ns1.example.net. ~
 example.net. +600 ns ns3.example.net. ~
 mail.example.net. +600 a 10.2.3.7 ~
 www.example.net. +600 a 10.2.3.11 ~

   Then the NS records will be "synth-ip" records.

   The zone should look like this:

 example.net. +600 soa ns1.example.net. hostmaster@example.net
 10 10800 3600 604800 1080 ~
 example.net. +600 ns ns1.example.net. ~
 example.net. +600 ns ns3.example.net. ~
 example.net. +600 mx 10 mail.example.net. ~
 example.net. +600 a 10.2.3.5 ~
 mail.example.net. +600 a 10.2.3.7 ~
 www.example.net. +600 a 10.2.3.11 ~

   This will remove the "synth-ip" records.

   To automate this process, this awk script is useful:

 fetchzone whatever.zone.foo 10.1.2.3 | awk '
 {if($3 ~ /ns/ || $3 ~ /soa/){print}
 else{a = a "\n" $0}}
 END{print a}' > zonefile.csv2

   Replace "whatever.zone.foo" with the name of the zone you are
   fetchin 10.1.2.3 with the IP address of the DNS master, and
   zonefile.csv2 with the name of the zone file MaraDNS loads.

Where is the root.hints file?

   MaraDNS, unlike BIND, does not need a complicated root.hints
   file in order to have custom root servers. In order to change
   the root.hints file, add something like this to your mararc
   file:

 root_servers["."] =  "131.161.247.232,"
 root_servers["."] += "208.185.249.250,"
 root_servers["."] += "66.227.42.140,"
 root_servers["."] += "66.227.42.149,"
 root_servers["."] += "65.243.92.254"

   Note that there is no "+=" in the first line, and the last line
   does not have a comma at the end. Read the recursive tutorial
   document for more information.

Are there any plans to use autoconf to build MaraDNS?

   No. OK, let me qualify that: I won't do it unless you pay me
   enough money.

   In more detail, MaraDNS does not use autoconf for the following
   reasons:

     * Autoconf is designed to solve a problem that existed in the
       mid 1990s but does not exist today: A large number of
       different incompatible C compilers and libc implementations.
       These days, most systems are using gcc as the compiler and
       some version of glibc as the libc. There is no longer a
       need, for example, to figure out whether a given
       implementation of getopt() allows '--' options. MaraDNS's
       ./configure script can be run in only a second or two;
       compare this to the 3-5 minute process autoconf's
       ./configure needs.
     * Autoconf leaves GPL-tained files in a program's build tree.
       MaraDNS is licensed under a BSD license that is not
       GPL-compatible, so MaraDNS can not be distributed with these
       GPL-licensed files.

   This leads us to the next question:

How do I change the compiler or compile-time flags with MaraDNS' build
process?

   To change the compiler used by MaraDNS:

     * Run the ./configure script
     * Open up the file Makefile with an editor
     * Look for a line that starts with CC
     * If there is no line that starts with CC, create one just
       before the line that starts with FLAGS
     * Change (or create) that line to look something like
       CC=gcc296 In this example, the 2.96 version of gcc is used
       to compile MaraDNS.
     * Note that it is important to not remove anything from this
       line you do not understand; doing so will make MaraDNS
       unable to compile or run. So, if the CC line looks like
       CC=gcc $(LDFLAGS) -DNO_FLOCK and you want to compile with
       gcc 2.96, change the line to look like
       CC=gcc296 $(LDFLAGS) -DNO_FLOCK retaining the flags added by
       the configuration script.

   Changing compile-time flags is a similar process:

     * Run the ./configure script
     * Open up the file Makefile with an editor
     * Look for a line that starts with FLAGS
     * Change (or create) that line to look something like
       FLAGS=-O3 In this example, MaraDNS is compiled with the -O3
       option.
     * Note that it is important to not remove anything from this
       line you do not understand; doing so will make MaraDNS
       unable to compile or run. So, if the FLAGS line looks like
       FLAGS=-O2 -Wall -DSELECT_PROBLEM and you want to compile at
       optimization level three, change this line to look like
       FLAGS=-O2 -Wall -DSELECT_PROBLEM retaining the flags added
       by the configuration script. -DSELECT_PROBLEM for example,
       is needed in the Linux compile or MaraDNS will have problems
       with freezing up.

Will you make a package for the particular Linux distribution I am
using?

   No. OK, let me qualify that: I won't do it unless you pay me
   enough money.

   There are MaraDNS packages for a number of different
   distributions of Linux and other operating systems. On the
   MaraDNS site, there is a MaraDNS package for CentOS/Red Hat
   Enterprise Linux available. There is also usually an up-to-date
   Slackware package available. In addition, there is a Debian
   package in the Debian packages collection, a FreeBSD port of
   MaraDNS, a Ubuntu package which is derived from the Debian
   package, and undoubtably other MaraDNS packages floating around
   the internet.

   If you wish to have a package for your particular version of
   Linux (or MacOS X or BSD or...), you can use one of the above
   packages as a starting point for making your package. For
   example, other RPM-based distributions can use the CentOS RPM
   package as a baseline (the .spec file is in the build/
   directory). I can not help you with any problems you may
   encounter making this package since I do not have your
   particular version of Linux installed on my computer.

   As an aside, some of the MaraDNS packages floating around on the
   internet are out of date (*cough*, Debian, *cough*)^1. Please
   make sure, that if you get a third-party package from the
   internet, the package is for either MaraDNS 1.0.41, MaraDNS
   1.2.12.08, or MaraDNS 1.3.07.05. Older versions of MaraDNS are
   not supported.

   Footnote 1: Debian has a somewhat silly policy that, once a
   package is declared "stable", they will basically not update it
   unless there is a Bugtraq security advisory for the package in
   question. This policy is a good policy for programs made by
   pimply-faced 16-year-olds who don't know how to manage a release
   cycle nor a bugfix-only branch, but doesn't make sense for
   MaraDNS. As I write this, the Debian's "stable" version of
   MaraDNS is 1.2.12.04, which is about a year behind in terms of
   bugfixes. I, annoyingly enough, get bug reports from Debian
   users telling me about bugs I have already fixed in the 1.2
   branch of MaraDNS.

   Now, to be fair to Debian, their policies do allow me to
   backport bugfixes to the 1.2.12.04 release of MaraDNS, and the
   patches do get reviewed by somone else, which minimizes bugfixes
   introducing new bugs (Yes, I have done that), but there are not
   enough volunteers to review all of the bugfixes I have made
   since 1.2.12.04. So, Debian users get stuck with an old, buggy
   version of MaraDNS. The policy would work if there were enough
   volunteers to actually review all of my post-1.2.12.04 bugfixes,
   but the people who created the policy did not take in to account
   the logistics of volunteer work.

I am using the native Windows port of MaraDNS, and some features are
not working.

   Since Windows 32 does not have some features that *NIX OSes
   have, the native Windows port does not have all of the features
   of the *NIX version of MaraDNS. In particular, the following
   features are disabled:

     * ipv6 (this is actually a mingw32, not a Windows deficiency)
     * The chroot_dir mararc variable
     * The maradns_gid and maradns_uid mararc variables
     * The maxprocs mararc variable
     * The synth_soa_serial variable can not have a value of 2

   If any of the above features are desired, try compiling MaraDNS
   using Cygwin. Note that the Cygwin port of MaraDNS does not have
   ipv6 support, and that while chroot_dir works in Cygwin, it does
   not have the security that the *NIX chroot() call has.

MaraDNS isn't starting up

   This is usually caused by a syntax error in one's mararc file,
   or by another MaraDNS process already running. To see what is
   happening, look at your system log (/var/log/messages in Centos
   3) to see what errors MaraDNS reports. If you do not know how to
   look at a system log, you can also invoke MaraDNS from the
   command line as root; any errors will be visible when starting
   MaraDNS.

You make a lot of releases of MaraDNS; at our ISP/IT department,
updating software is non-trivial.

   The number of releases seen in the changelog is not an
   accurate reflection of how often someone using a stable branch
   of MaraDNS will need to update.

   There were only three updates to the 1.0 legacy branch in 2006,
   and (so far) only two updates to the 1.0 branch in 2007. The 1.2
   branch was updated frequently in the first half of 2006, since I
   felt MaraDNS 1.2 needed some features that didn't make it in to
   1.2.00. During this update cycle, there was always a stable
   bugfix-only branch of MaraDNS.

   In August of 2006, I stabilized the 1.2 branch and only five
   updates have been done since then. Unless there is a critical
   bug, I only will update the 1.2 branch approximately once every
   six months or so.

   I go to a great deal of effort to make sure MaraDNS releases are
   as painless to update as possible. I ensure configuration file
   format compatibility, even between major versions of MaraDNS.
   With the exception of configuration file parser bugfixes,
   MaraDNS 1.0 configuration files are compatible with MaraDNS 1.2
   and 1.3.

   It is impossible to make code that is bug-free or without
   security problems. This is especially true with code that runs
   on the public internet.^1 Code has to be updated from time to
   time. What I do in order to minimize the disruption caused by an
   update is to always have a stable bugfix-only branch of MaraDNS
   (right now I have three bugfix-only branches), and to, as much
   as possible, evenly space out the bugfix updates.

   Footnote 1: Even DJB's code has security problems. Both Qmail
   and DjbDNS have known security problems, and need to be patched
   before put on a public internet server.

                                 BUGS

   In the unusual case of having a csv2 zone file with
   Macintosh-style newlines (as opposed to DOS or UNIX newlines),
   while the file will parse, any errors in the file will be
   reported as being on line 1.

   The maximum allowed number of threads is 5000.

   The system startup script included with MaraDNS assumes that the
   only MaraDNS processes running are started by the script; it
   stops all MaraDNS processes running on the server when asked to
   stop MaraDNS.

   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. This is
   somewhat worked around by having a CNAME record only stay in the
   recursive cache for 15 minutes.

   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
   question 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 receives 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 needs to use the zoneserver program to serve DNS records
   over TCP. See zoneserver(8) for usage information.

   MaraDNS does not use the zone file ("master file") format
   specified in chapter 5 of RFC1035.

   MaraDNS default behavior with star records is not RFC-compliant.
   In more detail, 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". This can be changed
   by setting bind_star_handling to 1.

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

   MaraDNS recursive resolver treats any TTL shorter than min_ttl
   seconds (min_ttl_cname seconds when the record is a CNAME
   record) as if the TTL in question was min_ttl (or min_ttl_cname)
   seconds long when determining when to expire a record from
   MaraDNS' cache.

   TTLs which are shorter than 20 seconds long are given a TTL of
   20 seconds; TTLs which are more than 63072000 (2 years) long are
   given a TTL of 2 years.

   MaraDNS' recursive resolver's method of deleting not recently
   accessed records from the cache when the cache starts to fill up
   can deleted records from the cache before they expire. Some
   people consider this undesirable behavior; I feel it is
   necessary behavior if one wishes to place a limit on the memory
   resources a DNS server may use.

   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.

   MaraDNS spawns a new thread for every single recursive DNS
   request when the data in question is not in MaraDNS' cache; this
   makes MaraDNS an excellent stress tester for pthread
   implementations. Many pthread implementations can not handle
   this kind of load; symptoms include high memory usage and
   termination of the MaraDNS process.

   MaraDNS does not handle the case of a glueless in-bailiwick NS
   referral very gracefully; this usually causes the zone pointed
   to by the offending NS record to be unreachable by MaraDNS, even
   if other DNS servers for the domain have correct NS referrals.

                        UNIMPLEMENTED FEATURES

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

   MaraDNS does not have a disk-based caching scheme for
   authoritative zones.

   MaraDNS' UDP server only loads zone files while MaraDNS is first
   started. UDP Zone information can only be updated by stopping
   MaraDNS, and restarting MaraDNS again. Note that TCP zone files
   are loaded from the filesystem at the time the client requests a
   zone.

   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 only has limited authoritative-only support for IPv6.

   MaraDNS only allows wildcards at the beginning or end of a host
   name. E.g. names with wildcards like "foo.*.example.com".
   "www.*" will work, however, if a default zonefile is set up.

   MaraDNS does not have support for MRTG or any other SNMP-based
   logging mechanism.

                           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.

                               AUTHORS

   Sam Trenholme (http://www.samiam.org) is responsible for
   this man page.

   MaraDNS is written by me, Sam Trenholme, with a little help from
   my friends. Naturally, all errors in MaraDNS are my own (but
   read the disclaimer above).

   Here is a partial list of people who have provided assistance:

   Floh has generously set up a FreeBSD 4, FreeBSD 6, and Mac OS X
   system so that I can port MaraDNS to more platforms.

   Albert Lee has provided countless bug reports, and, nicely
   enough, patches to fix said bugs. He has also made improvements
   to the code in the tcp "zoneserver".

   Franky Van Liedekerke has provided much invaluable assistance.
   As just one example, he provided invaluable assistance in
   getting MaraDNS to compile on Solaris. In addition, he has
   provided much valuable SQA help.

   Christian Kurz, who has provided invaluable bug reports,
   especially when I had to re-implement the core hashing
   algorithm.

   Remmy, who is providing both the web space and a mailing list
   for maradns.org.

   Phil Homewood, who provided invaluable assistance with finding
   and fixing bugs in the authoritative portion of the MaraDNS
   server. He helped me plug memory leaks, find uninitialized
   variables being used, and found a number of bugs I was unable to
   find.

   Albert Prats kindly provided Spanish translations for various
   text files.

   Shin Zukeran provided a patch to recursive.c which properly
   makes a normal null-terminated string from a js_string object,
   to send as an argument to open() so we can get the rijndael key
   for the PRNG.

   D Richard Felker III has provided invaluable bug reports. By
   looking at his bug reports, I have been able to hunt down and
   fix many problems that the recursive nameserver had, in addition
   to at least one problem with the authoritative nameserver.

   Ole Tange has also given me many valuable MaraDNS bug reports.

   Florin Iucha provided a tip in the FAQ for how to compile
   MaraDNS on OpenBSD.

   Roy Arends (one of the BIND developers, as it turns out) found a
   serious security problem with MaraDNS, where MaraDNS would
   answer answers, and pointed it out to me.

   Code used as the basis for the psudo-random-number generator was
   written by Vincent Rijmen, Antoon Bosselaers, and Paulo Barreto.
   I appreciate these programmers making the code public domain,
   which is the only license under which I can add code to MaraDNS
   under.

   Ross Johnson and others have made a Win32 port of the Pthreads
   library; this has made a native win32 port of MaraDNS possible.

   I also appreciate the work of Dr. Brian Gladman and Fritz
   Schneider, who have both written independent implementations of
   AES from which I obtained test vectors. With the help of their
   hard work, I was able to discover a subtle security problem that
   previous releases of MaraDNS had.
