~ubuntu-branches/ubuntu/natty/maradns/natty : contents of doc/en/source/mararc.ej.orig at revision 12

~ubuntu-branches/ubuntu/natty/maradns/natty : (revision 12)
<HEAD>
<TH>MARARC 5 "January 2002" MARADNS "MaraDNS reference"</TH>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=utf-8">
</HEAD>
<BODY>

<h1>NAME</h1>
mararc - Format of the mararc zone file that MaraDNS uses

<h1>MARARC FILE FORMAT</h1>
Mararc files use a syntax that is a subset of Python 2.2.3 syntax.  In
particular, Python 2.2.3 (and possibly other versions of Python) can read
a properly formatted mararc file without error.
<p>
Unlike Python, however, a mararc file can only use certain variable names, 
and the variables can only be declared as described below.
<p>
<h1>COMMENTS</h1>
Comments (lines ignored by the MaraDNS parser) start with the '#'
character, like this:
<pre>
# This is a comment
</pre>
The MaraDNS parser also ignores lines which contain only white space.

<h1>OPERATORS</h1>
The MaraRC file supports two operators: = and +=
<p>
The = operator can be used to assign both numeric and string values
<p>
The += operator can only be used on string values, and concatenates the
value to the right of the += operator to the string specified to the
left of the += operator.
<p>
Examples:
<pre>
ipv4_bind_addresses = "10.2.19.83"
ipv4_bind_addresses += ",10.2.66.74"
ipv4_bind_addresses += ",10.3.87.13"
</pre>

ipv4_bind_addresses now has the value "10.2.19.83,10.2.66.74,10.3.87.13"

<pre>
ipv4_alias["icann"] = "198.41.0.4"
ipv4_alias["icann"] += ",192.228.79.201"
ipv4_alias["icann"] += ",192.33.4.12,128.8.10.90"
</pre>

<h1>MARARC VARIABLES</h1>
Follows is a listing of variables that can be declared in the mararc file.

<h1>DICTIONARY VARIABLE FORMAT</h1>

A <b>dictionary variable</b>
is an array that can have multiple elements.  Unlike a traditional
array, these arrays are indexed by strings instead of numbers.  These
are analogous to associative arrays, or what Perl somewhat inaccurately
calls hashes.
<p>
The syntax of a dictionary variable is in the following form:
<pre>
name["index"] = "value"
</pre>
Where <b>name</b> is the name of the dictionary variable,
<b>index</b> is the index of the array, and
<b>value</b> is the value stored at that index.
<p>
Every time we have a dictionary-type variable (such as csv2),
we must first initialize it using a line in the following form:
<pre>
csv2 = {}
</pre>
Here, csv2 is the name of the "dictionary" variable that we are
initializing.

<h1>DICTIONARY VARIABLES</h1>

Here is a listing of all "dictionary"-style variables that MaraDNS
uses:

<h2>csv2</h2>

The csv2 dictionary variable stores all of the zone names and file names
for the zone files that MaraDNS uses.  Note that csv2 files are read
after MaraDNS is chrooted.  Hence the filename is relative to the
chroot_dir.

Example:

<pre>
csv2["example.net."] = "db.example.net"
</pre>

See 
<b>csv2(5)</b> 
for a description of this file's format.

<h2>csv1</h2>

csv1: Used to indicate the filename to use for a given zone stored in 
the legacy csv1 zone file format.  This is primarily for compatibility
with people who have maradns-1.0 zone files.
<pre>
csv1["zone"] = "filename"
</pre>
<b>csv1</b>:
A pipe-separated-file. See
<b>csv1(5)</b>.
<p>
<b>zone</b>:
the zone that file in question is authoritative for 
<p>
<b>filename</b>:
the file with the CSV1 zone data
<p>
Note that csv1 files are read after MaraDNS is chrooted, and,
hence the filename is relative to the chroot_dir.
<p>
See the <b>csv1(5)</b> man page for more information on this file format.

<h2>ipv4_alias</h2>

ipv4_alias: Used to give nicknames or aliases for ip/netmask
pairs for ipv4 (standard 32-bit) IP addresses.

<pre>
ipv4_alias["name"] = "ip1/netmask,ip2/netmask,etc"
</pre>

<b>name</b>: The name of the alias in question 
<p>

<b>ip</b>: The ip portion of an ip/netmask pair 
<p>

<b>netmask</b>: the mask portion of an ip/netmask pair 
<p>

<b>,</b>: Used to separate ip/netmask pairs.  Spaces may be placed before or
after this comma.
<p>

An ip is in dotted-decimal format, e.g. "10.1.2.3".
<p>

The netmask can be in one of two formats: A single number between
1 and 32, which indicates the number of leading "1" bits in the
netmask, or a 4-digit dotted-decimal netmask.
<p>

The netmask is used to specify a range of IPs.
<p>

<h2>ipv4_alias examples</h2>

<b>10.1.1.1/24</b> indicates that any ip from 10.1.1.0 to 10.1.1.255
will match.  
<p>

<b>10.1.1.1/255.255.255.0</b> is identical to 10.1.1.1/24
<p>

<b>10.2.3.4/16</b> indicates that any ip from 10.2.0.0 to 10.2.255.255 
will match.  
<p>

<b>10.2.3.4/255.255.0.0</b> is identical to 10.2.3.4/16
<p>

<b>127.0.0.0/8</b> indicates that any ip with "127" as the first 
octet (number) will match.  
<p>

<b>127.0.0.0/255.0.0.0</b> is identical to 127.0.0.0/8
<p>

The netmask is optional, and, if not present, indicates that only
a single IP will "match".  e.g:
<p>

<b>10.9.9.9/32</b>, <b>10.9.9.9/255.255.255.255</b>, and <b>10.9.9.9</b>
are all functionally identical, and indicate that only the ip 10.9.9.9
will match.
<p>

The significance of "match" depends on what we use the ipv4
alias for.
<p>

ipv4 aliases can nest.  E.g:
<pre>
ipv4_alias["susan"] = "10.6.7.8/24" 
ipv4_alias["office"] = "susan,10.9.9.9"
</pre>

Where "susan" in the "office" alias matches the value of the
ipv4_alias susan.
<p>

Multiple levels of nesting are allowed.  Self-referring nests will
result in an error.
<p>

<h2>root_servers</h2>

root_servers:  This is a special "dictionary" element that can
(currently) only have one element: ".", which points to either
an ip, or a pointer to an ipv4 alias which is a listing of root name 
servers.

<pre>
root_servers["."] = "list_of_servers"
</pre>

Where "." is the only allowed array reference for the root servers
(this format is used to allow potential future expansion), and
list_of_servers is a list of root name servers in the exact same
format as ipv4_aliases.
<p>

Note that, while ips in the list of root name servers can have
netmasks, the netmask portion is ignored.
<p>

The root_servers should only point to root servers.  If one wishes to use
MaraDNS as a forwarding name server, which forwards DNS requests on to 
another server, use the upstream_servers variable instead.

<h2>upstream_servers</h2>

This is identical to the root_servers variable (can have only one
element, the element is a list of ipv4_addresses, the variable is a 
dictionary variable, etc.), but is used
when one wishes to use MaraDNS to query other recursive servers, instead
of querying the actual root name servers for an answer.
<p>

Note that one can not have both root_servers and upstream_servers set
in a given mararc file; MaraDNS will return with a fatal error if one
attempts to do this.
<p>

If you get a syntax error when trying to use upstream_servers, please 
search for upstream_servers in the
MaraDNS FAQ and read this entry, or look for upstream_servers
in the example mararc file below for an example of correct usage
of this variable.

<h2>Final note on dictionary variables</h2>

csv1, csv2, ipv4_alias, and root_servers are currently the only existing
dictionary variables.

<h1>NORMAL VARIABLE FORMAT</h1>

Normal variables.  These are variables that can only take
a single value.
<p>

The syntax of a normal variable is in the form
<pre>
name = "value"
</pre>

Where <b>name</b> is the name of the normal variable, and <b>value</b>
is the value of the variable in question.

<h1>NORMAL VARIABLES</h1>

Here is a listing of normal variables that MaraDNS
uses:

<h2>ipv4_bind_addresses</h2>

ipv4_bind_addresses:  The IP addresses to give the MaraDNS server.
<p>

This accepts one or more ipv4 IPs in dotted-decimal (e.g. "127.0.0.1")
notation, and specifies what IP addresses the MaraDNS server will
listen on.  Multiple bind addresses are separated with a comma, like
this: "10.1.2.3, 10.1.2.4, 127.0.0.1"
<p>

<h2>admin_acl</h2>

This is a list of ip/netmask pairs that are allowed to get certain
administrative information about MaraDNS, including:
<ul>
<li>The version number of MaraDNS running 
<li>The number of threads MaraDNS has 
<li>MaraDNS' internal timestamp value
</ul>

Note that this information is not available unless
the mararc variable debug_msg_level is sufficiently high.
See the information on debug_msg_level below for details on this
and on the TXT queries sent to get the above information. 

<h2>bind_address</h2>

bind_address:  The IP address to give the MaraDNS server.
<p>

This accepts a single IP in dotted-decimal (e.g. "127.0.0.1")
notation, and specifies what IP address the MaraDNS server will
listen on.  Note that ipv4_bind_addresses has the same functionality.
This name is included so that MaraDNS 1.0 configuration files will 
continue to work with MaraDNS 1.2.
<p>

<h2>bind_star_handling</h2>

In the case where there is both a star record for a given name and recordtype,
a non-star record with the same name but a different recordtype, and no record
for the given name and recordtype, MaraDNS will usually return the
star record.  BIND, on the other hand, will return a "not there" reply.

In other words:

<ul>
<li>If a non-A record for <tt>foo.example.com</tt> exists
<li>An A record for <tt>*.example.com</tt> exists
<li>No A record for <tt>foo.example.com</tt> exists
<li>And the user asks for the A record for <tt>foo.example.com</tt>
<li>MaraDNS will usually return the A record attached to <tt>*.example.com</tt>
<li>BIND, on the other hand, returns a "not there" for <tt>foo.example.com</tt>
</ul>

If the BIND behavior is desired, set <tt>bind_star_handling</tt> to 1.  
Otherwise, set this to 0 (the default value if this is not set at all
in the <tt>mararc</tt> file).  

<p>

MaraDNS will exit with a fatal error if <tt>bind_star_handling</tt> has
any value besides 0 or 1.

<h2>chroot_dir</h2>
chroot_dir: The directory MaraDNS chroots to
<p>

This accepts a single value:  The full path to the directory to
use as a chroot jail.
<p>

Note that csv1 zone files are read after the chroot operation.
Hence, the chroot jail needs to have any and all zone files that
MaraDNS will load.

<h2>csv2_default_zonefile</h2>
This is a special zone file that allows there to be stars at the <i>end</i>
of hostnames.  This file is similar to a normal csv2 zone file, but has
the following features and limitations:

<ul>
<li>Stars are allowed at the end of hostnames
<li>A SOA record is mandatory
<li>NS records are mandatory
<li>Neither CNAME nor FQDN4 records are permitted in the zone file
<li>Delegation NS records are not permitted in the zone file
<li>Default zonefiles may not be transferred via zone transfer
<li>Both recursion and default zonefiles may not be enabled at the same
    time.
</ul>

<h2>csv2_synthip_list</h2>
Sometimes the IP list of nameservers will be different than the 
nameservers one is bound to.  This allows the synthetic nameserver list
to have different IPs.  

<p>

Note that this may act in an unexpected manner
if routable and non-routable (localhost and RFC1918) addresses are 
combined; in particular, a list with both routable and non-routable
addresses will discard the non-routable IP addresses, and a list with
rfc1918 and localhost addresses will discard the localhost addresses.

<h2>debug_msg_level</h2>

This is a number indicating what level of information about a running 
MaraDNS process should be made public.  When set to 0, no information
will be made public.  
<p>
When set to one (the default), or higher, a 
Tversion.maradns. (TXT query for 
"version.maradns.") query will return the version
number of MaraDNS.  
<p>
When set to two or higher, a Tnumthreads.maradns.
(TXT query for "numthreads.maradns.") 
query will return the 
number of threads that MaraDNS is currently running, and a 
Tcache-elements.maradns.
query will return the number of elements in MaraDNS' cache.  
<p>
If MaraDNS is compiled with debugging information on, a 
Tmemusage.maradns. query will return the amount of memory MaraDNS has
allocated.  Note that the overhead for tracking memory usage is considerable
and that compiling MaraDNS with "make debug" will greatly slow down MaraDNS.
A debug build of MaraDNS is <b>not</b> reccomended for production use.
<p>
When set to three or higher, a Ttimestamp.maradns. query will return, in 
seconds since the UNIX epoch, the timestamp for the system MaraDNS
is running on.
<br>

<h2>default_rrany_set</h2>
This variable used to determine what kind of resource records were returned
when an ANY query was sent.  In MaraDNS 1.2, the data structures have been 
revised to return any resource record type when an ANY query is sent; this
variable does nothing, and is only here so that MaraDNS 1.0 mararc files
will continue to work.

The only accepted values for this variable were 3 and 15.

<h2>dos_protection_level</h2>
If this is set to a non-zero value, certain features of MaraDNS will be
disabled in order to speed up MaraDNS' response time.  This is designed for
situtations when a MaraDNS server is receiving a large number of queries,
such as during a denial of service attack.  

<p>

This is a numeric variable; its default value is zero, indicating that all
of MaraDNS' normal features are enabled.  Higher numeric values
disable more features:

<ul>

<li>A dos_protection_level of 1 or above disables getting MaraDNS status
    information remotely

<li>A dos_protection_level of 8 or above disables CNAME lookups.

<li>A dos_protection_level or 12 or above diables delegation NS records.

<li>A dos_protection_level of 14 or above disables ANY record processing

<li>A dos_protection_level of 18 or above disables star record processing
    at the beginning of hostnames (default_zonefiles still work, however)

</ul>

<h2>ipv6_bind_address</h2>
If MaraDNS is compiled with as an authoritative server, then this 
variable will tell MaraDNS which ipv6 address for the UDP server to; 
for this variable to be set, MaraDNS must be bound to at least one 
ipv4 address.

<h2>handle_noreply</h2>
This is a numeric variable which determines how the recursive resolver
informs the client that Mara was unable to contact any remote DNS servers
when trying to resolve a given domain.  

If this is set to 0, no reponse will be sent to the DNS client.

If this is set to 1, a "server fail" message will be sent to the DNS client.

If this is set to 2, a "this host does not exist" message will be sent
to the DNS client.

The default value for this is 1.

<h2>hide_disclaimer</h2>
If this is set to "YES", MaraDNS will not display the legal disclaimer when
starting up.

<h2>long_packet_ipv4</h2>
This is a list of IPs which we will send UDP packets longer than the 512 bytes
RFC1035 permits if necessary.  This is designed to allow <tt>zoneserver</tt>,
when used send regular DNS packets over TCP, to receive packets with more 
data than can fit in a 512-byte DNS packet.
<p>

This variable only functions if MaraDNS is compiled as an authoritative 
only server.

<h2>maradns_uid</h2>
maradns_uid: The numeric UID that MaraDNS will run as
<p>

This accepts a single numerical value: The UID to run MaraDNS as.
<p>

MaraDNS, as soon as possible drops root privileges, minimizing the
damage a potential attacker can cause should there be a security
problem with MaraDNS.  This is the UID maradns becomes.
<p>
The default UID is 99.

<h2>maradns_gid</h2>
maradns_gid: The numeric GID that MaraDNS will run as.
<p>

This accepts a single numerical value: The GID to run MaraDNS as.
<p>

The default GID is 99.

<h2>maximum_cache_elements</h2>
maximum_cache_elements: The maximum number of elements we can have
in the cache of recursive queries.
<p>

This cache of recursive queries is used to store entries we have
previously obtained from recursive queries.
<p>

If we approach this limit, the "custodian" kicks in to effect.
The custodian removes elements at random from the cache (8 elements
removed per query) until we are at the 99% or so level again.

<p> The default value for this variable is 1024.
<h2>maxprocs</h2>
maxprocs: The maximum number of threads or processes that MaraDNS
is allowed to run at the same time.
<p>

This variable is used to minimize the impact on the server when
MaraDNS is heavily loaded.  When this number is reached, it is
impossible for MaraDNS to spawn new threads/processes until the
number of threads/processes is reduced.
<p> The default value for this variable is 64.
<p>
The maximum value this can have is 500.
<h2>max_ar_chain</h2>
max_ar_chain: The maximum number of records to display if a record in
the additional section (e.g., the IP of a NS server
or the ip of a MX exchange) has more than one value.
<p>

This is similar to max_chain, but applies to records in the
"additional" (or AR) section.
<p>

Due to limitations in the internal data structures that MaraDNS
uses to store RRs, if this has a value besides one, round robin
rotates of records are disabled.

<p> The default value for this variable is 1.

<h2>max_chain</h2>
max_chain: The maximum number of records to display in a chain
of records.
<p>

With DNS, it is possible to have more than one RR for a given
domain label.  For example, "example.com" can have, as the A record,
a list of multiple ip addresses.
<p>

This sets the maximum number of records MaraDNS will show for a
single RR.
<p>

MaraDNS normally round-robin rotates records.  Hence, all records
for a given DNS label (e.g. "example.com.") will be visible,
although not at the same time if there are more records than the
value allowed with max_chain

<p> The default value for this variable is 8.

<h2>max_glueless_level</h2>
Maximum glueless level allowed when performing recursive lookups.  The
default value is 10.  
<p>

This is the maximum number of times MaraDNS will "go back to the root 
servers" in order to find out the IP of a name server for which we do
not have a glue IP for, or to find out the A value for a given CNAME
record.  

<h2>max_queries_total</h2>
Maximum number of queries to perform when performing recursive lookups.  The
default value is 32.  
<p>

This is the maximum number of times MaraDNS will send a query to 
nameservers in order to find out the answer to a DNS question.

<h2>max_tcp_procs</h2>
max_tcp_procs: The (optional) maximum number of processes the zone
server is allowed to run.
<p>

Sometimes, it is desirable to have a different number of maximum
allowed tcp processes than maximum allowed threads.  If this
variable is not set, the maximum number of allowed tcp processes is
"maxprocs".

<h2>max_total</h2>
max_total: The maximum number of records to show total for a given
DNS request.
<p>

This is the maximum total number of records that MaraDNS will make
available in a DNS reply.

<p> The default value for this variable is 20.
<h2>min_ttl</h2>
min_ttl: The minimum amount of time a resource record will stay in
MaraDNS' cache, regardless of the TTL the remote server specifies.
<p>

Setting this value changes the minimum amount of time MaraDNS'
recursive server will keep a record in the cache.  The value is
in seconds.

<p>
The default value of this is 300 (5 minutes); the minimum value
for this is 180 (2 minutes).

<h2>min_ttl_cname</h2>
min_ttl_cname: The minimum amount of time a resource record
will stay in MaraDNS' cache, regardless of the TTL the remote server
specifies.
<p>

Setting this value changes the amount of time a CNAME record stays
in the cache.  The value is in seconds.

<p>
The default value for this is the value min_ttl has; the minimum value
for this is 180 (2 minutes).

<h2>min_visible_ttl</h2>
min_visible_ttl: The minimum value that we will will show as the TTL (time
to live) value for a resource record to other DNS servers and stub resolvers.
In other words, this is the minimum value we will ask other DNS server to
cache (keep in their memory) a DNS resource record.  
<p>

The value is in seconds.  The default value for this is 30; the minimum 
value this can have is 5.  People running highly loaded MaraDNS servers 
may wish to increase this value to 3600 (one hour) in order to reduce the
number of queries recursively processed by MaraDNS.
<p>

As an aside, RFC1123 section 6.1.2.1 implies that zero-length TTL records 
should be passed on with a TTL of zero.  This, unfortunatly, breaks some
stub resolvers (such as Mozilla's stub resolver).

<h2>no_fingerprint</h2>
no_fingerprint: Flag that allows MaraDNS to be harder to detect.
<p>

Some people do not feel it is appropriate to have some information,
such as the version number of MaraDNS being run, be publicly
available.
<p>

The default value is 0.
<p>

By setting no_fingerprint to 1, it is possible to have MaraDNS not
reveal this information publicly.

<h2>random_seed_file</h2>
randsom_seed_file:  The file from which we read 16 bytes from to
get the 128-bit seed for the secure pseudo random number generator.
<p>

This localcation of this file is relative to the root of the
filesystem, not MaraDNS' chroot directory.
<p>

This is ideally a file which is a good source of random numbers
(e.g. /dev/urandom), but can also be a fixed file if your OS does not
have a decent random number generator.	In that case, make sure the
contents of that file is random and with 600 perms, owned by root.
We read the file <b>before</b> dropping root privileges.

<h2>recursive_acl</h2>
recursive_acl: List of ips allowed to perform recursive queries with
the recursive portion of the MaraDNS server
<p>

The format of this string is identical to the format of an ipv4_alias
entry.

<h2>remote_admin</h2>
remote_admin: Whether we allow <tt>verbose_level</tt> to be changed
after MaraDNS is started.
<p>

If <tt>remote_admin</tt> is set to 1, and <tt>admin_acl</tt> is set,
any and all IPs listed in <tt>admin_acl</tt> will be able to 
reset the value of <tt>verbose_level</tt> from any value between 0
and 9 via a TXT query in the form of <tt>5.verbose_level.maradns.</tt>
What this will do is set <tt>verbose_query</tt> to the value in the
first digit of the query.  
<p>

This is useful when wishing to temporarily increase the 
<tt>verbose_level</tt> to find out why a given host name is not
resolving, then decreasing <tt>verbose_level</tt> so as to minimize
the size of MaraDNS' log.

<h2>retry_cycles</h2>
retry_cycles: The number of times the recursive resolver will try to contact 
all of the DNS servers to resolve a given name before giving up.  This 
feature was added to MaraDNS 1.2.08, and has a default value of 2.

<h2>spammers</h2>
spammers: A list of DNS servers which the recursive resolver will
not query.
<p>

This is mainly used to not allow spam-friendly domains to
resolve, since spammers are starting to get in the habit of using
spam-friendly DNS servers to resolve their domains, allowing them
to hop from ISP to ISP.
<p>

The format of this string is identical to the format of an ipv4_alias
entry.

<h2>synth_soa_origin</h2>
When a CSV2 zone file doesn't have a SOA record in it, MaraDNS generates
a SOA record on the fly.  This variable determines the host name for
the "SOA origin" (which is called the MNAME in RFC1035); this is the
host name of the DNS server which has the "master copy" of a given
DNS zone's file.  
<p>
This host name is in human-readable format without a trailing dot,
e.g.:
<pre>
synth_soa_origin = "ns1.example.com"
</pre>
If this is not set, a synthetic SOA record will use the name of the
zone for the SOA origin (MNAME) field. 

<p>

<h2>synth_soa_serial</h2>
This determines whether we strictly follow RFC1912 section 2.2 with
SOA serial numbers.  If this is set to 1 (the default value), we do 
not strictly follow RFC1912 section 2.2 (the serial is a number, based
on the timestamp of the zone file, that is updated every six seconds), but
this makes it so that a serial number is guaranteed to be automatically
updated every time one edits a zone file.

<p>
If this is set to 2, the SOA serial number will be in YYYYMMDDHH format,
where YYYY is the 4-digit year, MM is the 2-digit month, DD is the 2-digit 
day, and HH is the 2-digit hour of the time the zone file was last updated
(GMT; localtime doesn't work in a chroot() environment).  While this
format is strictly RFC1912 compliant, the disadvantage is that more than
one edit to a zone file in an hour will not update the serial number.  

<p>
I strongly recommend, unless it is extremely important to have a
DNS zone that generates no warnings when tested at dnsreport.com, to have
this set to 1 (the default value).  Having this set to 2 can result in
updated zone files not being seen by slave DNS servers.

<p>
Note that synth_soa_serial can only have a value of 1 on the native
Windows port.

<h2>tcp_convert_acl</h2>
This only applies to the zoneserver (general DNS-over-TCP) program.
<p>

This is a list of IPs which are allowed to connect to the zoneserver and
send normal TCP DNS requests.  The zoneserver will convert TCP DNS
requests in to UDP DNS requests, and send the UDP request in question
to the server specified in <b>tcp_convert_server</b>.  Once it gets a 
reply from the UDP DNS server, it will convert the reply in to a TCP
request and send the reply back to the original TCP client.

<p>
Whether the RD (recursion desired) flag is set or not when converting a TCP
DNS request in to a UDP DNS request is determined by whether the TCP client
is on the <b>recursive_acl</b> list.

<h2>tcp_convert_server</h2>
This only applies to the zoneserver (general DNS-over-TCP) program.
<p>

This is the UDP server which we send a query to when converting DNS TCP
queries in to DNS UDP servers.  Note that, while this value allows
multiple IPs, all values except the first one are presently
ignored.

<h2>timeout_seconds</h2>
This only applies when performing recursive lookups.  
<p>

The amount of time, in seconds, to wait for a reply from a remote DNS 
server before giving up and trying the next server on this list.  The 
default value is 2 seconds.
<p>
This is for setups where a recursive MaraDNS server is on a slow
network which takes more than two seconds to send and receive a DNS
packet.
<p>

Note that, the larger this value is, the slower MaraDNS will process 
recursive queries when a DNS server is not responding to DNS queries.

<h2>timestamp_type</h2>
timestamp_type: The type of timestamp to display.  The main purpose of
this option is to supress the output of timestamps.  Since duende uses
syslog() to output data, and since syslog() adds its own timestamp, this
option should be set to 5 when maradns is invoked with the duende tool.

<p>

This option also allows people who do not use the duende tool to view
human-readable timestamps.  This option only allows timestamps in GMT,
due to issues with showing local times in a chroot() environment.

<p>

This can have the following values:
<dl>
<dt>0
<dd>The string "Timestamp" followed by a UNIX timestamp
<dt>1
<dd>Just the bare UNIX timestamp
<dt>2
<dd>A GMT timestamp in the Spanish language
<dt>3
<dd>A (hopefully) local timestamp in the Spanish language
<dt>4
<dd>A timestamp using asctime(gmtime()); usually in the English language
<dt>5
<dd>No timestamp whatsoever is shown (this is the best option when
    maradns is invoked with the <tt>duende</tt> tool).
<dt>6
<dd>ISO GMT timestamp is shown
<dt>7
<dd>ISO local timestamp is shown
</dl>

<p> The default value for this variable is 5.

<h2>verbose_level</h2>
verbose_level: The number of messages we log to stdout
<P>

This can have five values:
<dl>
<dt>0
<dd>No messages except for the legal disclaimer and fatal parsing errors
<dt>1
<dd>Only startup messages logged (Default level)
<dt>2
<dd>Error queries logged 
<dt>3
<dd>All queries logged 
<dt>4
<dd>All actions adding and removing records from the cache logged
</dl>

<p> The default value for this variable is 1.

<h2>verbose_query</h2>
verbose_query: Whether to verbosely output all DNS queries that the
recursive DNS server receives.  If this is set to 1, then all recursive
queries sent to MaraDNS will be logged.  

<p>

This is mainly used for debugging.

<h2>zone_transfer_acl</h2>
zone_transfer_acl: List of ips allowed to perform zone transfers
with the zone server
<p>

The format of this string is identical to the format of an ipv4_alias
entry.

<h1>EXAMPLE MARARC FILE</h1>

<pre>
<include "../source/example_full_mararc">
</pre>

<h1>BUGS</h1>
If one should declare the same the same index twice with
a dictionary variable, MaraDNS will exit with a fatal error.  This is
because earlier versions of MaraDNS acted in a different manner than
Python 2.3.3.  With Python 2.3.3, the last declaration is used, while 
MaraDNS used to use the first declaration.

<h1>LEGAL DISCLAIMER</h1>
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. 
</body>