samboy/MaraDNS
1
3
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Let’s now have the actual Markdown man pages

Browse source
This commit is contained in:
Sam Trenholme 2023-02-27 06:08:09 -08:00
parent 348bb2ed3b
commit e0de36042a
15 changed files with 6004 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

967
doc/en/md/Deadwood.md Normal file
View file

File diff suppressed because it is too large Load diff

139
doc/en/md/askmara.md Normal file
View file

@ -0,0 +1,139 @@
# NAME
askmara - do simple dns queries
# DESCRIPTION
**askmara** queries the user-specified dns server for records, and
outputs the reply in a csv2-compatible format (csv2 is the format of
zone files that **maradns** uses).
# USAGE
**askmara** [-n] [ -v | -t timeout] query [ server ]
# OPTIONS
`-t` If this is present, the following argument is the askmara timeout,
in seconds. Note that **askmara** can not both have a user-defined
timeout and verbose output.
`-v` If this is set, **askmara** will verbosely output the complete
reply that the server sent. Note that this verbose output is not
csv2-compatible.
`-n` If this is set, **askmara**, when sending out a query, will not
request DNS recursion; in other words, askmara will request that the
remote DNS server not contact other DNS servers to answer the query in
question.
`query` dns record to be queried. The query has two sections: The type
of record we desire, and the hostname we want this record for.
The type of query can have two forms: A one-letter mnemonic, or a
numeric rtype followed by a colon. This is immediately concatenated by
the full name of the host name we wish to look up.
For example, to ask for the IP of 'example.com.', we can use the
one-letter mnemonic, in the form 'Aexample.com.', or we can use the
numeric RR followed by a colon, giving the query '1:example.com.'
(since A has the record type of one). Note that the query name needs
the trailing dot at the end.
Askmara supports a handful one-letter mnemonics, as follows:
**A** signifies a request for an A (ipv4 address) RR
**N** signifies a NS RR
**C** signifies that we are asking for a CNAME RR
**S** signifies that we want a SOA RR
**P** signifies that we want a PTR RR
**@** signifies that we mant a MX RR
**T** signifies that we want a TXT RR
**Z** signifies that we want to ask for all RRs.
`server` IP address of the dns server to be queried. If no server is
given, askmara will query 127.0.0.1.
# EXAMPLES
Asking the server with the ip 127.0.0.1 for the IP address of
example.com:
```
askmara Aexample.com.
```
Asking the server with the ip 198.41.0.4 for the IP address of
example.com:
```
askmara Aexample.com. 198.41.0.4
```
Asking the server with the ip address 127.0.0.1 for the IP
address of example.com, using the rr_number:query format:
```
askmara 1:example.com.
```
Asking the server with the ip address 127.0.0.1 for a SRV record.
In particular, we ask for the "http over tcp" service for example.net.
Since askmara doesn't have a mnemonic for SRV record types, we use the
numeric code (33 for SRV):
```
askmara 33:_http._tcp.example.net.
```
Asking the server with the ip address 127.0.0.1 for the AAAA
(ipv6 ip) record for example.net:
```
askmara 28:example.net.
```
Note that the output will be a raw DNS packet in the SRV example,
but askmara shows an IPv6 address (albeit without :: to collapse 0
quads) in the AAAA example.
# BUGS
When askmara is asked for an SOA record, the output of **askmara**
closely resembles the format of a csv2 file, but can not be parsed as a
csv2 file without modification.
askmara outputs multi-chunk ("character-string") TXT records
incorrectly (it only outputs the first chunk).
# SEE ALSO
**maradns(8)**
http://www.maradns.org
# 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
MaraDNS is written by Sam Trenholme. Jaakko Niemi used 5 minutes to
roll this manpage together, which Sam has subsequently revised.

143
doc/en/md/blockHashMake.md Normal file
View file

@ -0,0 +1,143 @@
# NAME
blockHashMake - Make a block hash file for Deadwood
# DESCRIPTION
blockHashMake is a stand alone command line tool which converts a list
of host names in to a *block hash file* which Deadwood can read to
block a large number of hosts quickly while using a minimum amount of
memory to store the list of blocked hosts.
A block hash file uses a special binary format for storing a list of
blocked host names.
blockHashMake reads the list of host names from the standard input and
generates a binary file.
# COMMAND LINE ARGUMENTS
blockHashMake can be invoked without command line arguments. If invoked
without arguments, blockHashMake reads the list of host names to block
from standard input and outputs the block hash to a file name
"bigBlock.bin"
blockHashMake can be invoked with a single "--help" or "--version"
command line argument (e.g. "blockHashMake --version") which will
output the version number of blockHashMake and provide basic usage
information.
The command line arguments are as follows:
```
blockHashMake [filename] [sip hash key] [hash bucket count]
```
The **filename** is the name of the file we output the block hash
to. If not specified, blockHashMake will output to the file named
"bigBlock.bin". blockHashMake should not clobber an already existing
file; if a file named "bigBlock.bin" (or the filename specified on the
command line) already exists, be sure to delete the file before
invoking blockHashMake to recreate the file.
The **sip hash key** is usually set by the blockHashMake program,
which, by default, uses /dev/urandom to generate a random 64-bit key
for the block hash file (the Windows port of blockHashMake uses the
CryptGenRandom function to get a random 64-bit key). If the **sip hash
key** is given a value of 0, this can make a block hash file which can
be shared on the internet.
*Warning*: For security purposes, please set the sip hash key to 0 if
sharing a block hash file on the internet!
Deadwood will only load a block hash file with a sip hash key of 0 if
allow_block_hash_zero_key has a value of 1.
A user specified sip hash key only has up to 16 bits of entropy. **sip
hash key** should *not* be used if a secret key for the hash
compression algorithm is desired.
The **hash bucket count** is the number of hash buckets the resulting
block hash file will have. Having more hash buckets makes the block
hash file larger, but sometimes allows searching for a string in a
block hash to be a little faster. The default value, which is 125% of
the number of host names given to blockHashMake, is a reasonable
compromise between speed and size.
# HOST LIST FORMAT
After being invoked, blockHashMake reads a list of host names from the
standard input. The format is a single host name per line of input,
such as the following:
```
porn.example.com
naughty.foo
evil.host.invalid
```
Each line is a host name. Should there be a duplicate host name,
blockHashMake will only store one instance of the host name in
question. Host names are case insensitive; upper case ASCII letters are
converted in to lower case letters beofre adding the host name to the
block hash generated by blockHashMake.
In order to allow there to be notes in files that blockHashMake reads,
blockHashMake has simple support for comments: Any line which begins
with the `#` character will be ignored by the blockHashMake program.
Note that the `#` character *must* be at the very beginning of a line
for the line to be ignored by BlockHashMake.
For example:
```
# Porn sites
porn.example.com
fetish.example.net
# Phishing sites
naughty.foo
evil.host.invalid
```
This will add `porn.example.com`, `fetish.example.net`,
`naughty.foo`, and `evil.host.invalid` to the block hash file, while
ignoring the two lines which start with `#`.
blockHashMake has no support for Punycode. Please use another program
to convert international domain names with non-ASCII characters in to
their punycode representation before adding them to a block hash with
blockHashMake.
# LIMITATIONS
The block hash format that blockHashMake uses is a 32-bit format, and
the resulting block hash file should be under 2,147,483,648 bytes in
size. This is a limitation of around 30 million host names.
# LEGAL DISCLAIMERS
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.
This is a project developed on a strictly volunteer, non-commercial
basis. It has been developed outside the course of a commercial
activity, developed entirely in the Americas (i.e. *outside of Europe*)
and therefore is not subject to the restrictions or conditions of the
proposed EU Cyber Resilience Act. Someone selling a product that uses
any component of this may be subject to this act and may need to handle
any and all necessary compliance.
# AUTHORS
Sam Trenholme (https://www.samiam.org) is responsible for this program
and man page.

87
doc/en/md/blockHashRead.md Normal file
View file

@ -0,0 +1,87 @@
# NAME
blockHashRead - Read a block hash file
# DESCRIPTION
blockHashRead is a stand alone command line tool which converts a
*block hash file* in to a list of hostnames. This way, a binary block
hash file can be converted in to an ASCII list of host names, edited,
and then converted back in to a binary block hash file with the
**blockHashMake** utility.
A block hash file uses a special binary format for storing a list of
blocked host names.
# USAGE
blockHashRead is invoked as follows:
```
blockHashRead --dump bigBlock.bin
```
Replace "bigBlock.bin" with the filename for the block hash file.
Doing this will output, on standard output, a list of host names in the
block hash file. Each line will contain a single host name. When
compiled for *NIX, the output will use *NIX line feeds; the Windows
port of blockHashRead uses DOS line feeds.
blockHashRead can be invoked with a single "--help" or "--version"
command line argument (e.g. "blockHashRead --version") which will
output the version number of blockHashRead and provide basic usage
information.
# HOST LIST FORMAT
After being invoked, blockHashRead writes a list of host names to the
standard output. The format is a single host name per line of input,
such as the following:
```
porn.example.com
naughty.foo
evil.host.invalid
```
Each line is a host name.
blockHashRead has no support for Punycode. Please use another program
to convert international domain names with non-ASCII characters in to
their non-punycode representation if seeing correct international
domain names is desired.
# LIMITATIONS
The block hash format that blockHashRead looks at is a 32-bit format,
and the resulting block hash file should be under 2,147,483,648 bytes
in size. This is a limitation of around 30 million host names.
# LEGAL DISCLAIMERS
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.
This is a project developed on a strictly volunteer, non-commercial
basis. It has been developed outside the course of a commercial
activity, developed entirely in the Americas (i.e. *outside of Europe*)
and therefore is not subject to the restrictions or conditions of the
proposed EU Cyber Resilience Act. Someone selling a product that uses
any component of this may be subject to this act and may need to handle
any and all necessary compliance.
# AUTHORS
Sam Trenholme (https://www.samiam.org) is responsible for this program
and man page.

629
doc/en/md/coLunacyDNS.md Normal file
View file

File diff suppressed because it is too large Load diff

227
doc/en/md/csv1.md Normal file
View file

@ -0,0 +1,227 @@
# NAME
csv1 - Format of the csv1 zone file that MaraDNS uses
# SPECIAL NOTE
The csv1 zone file format is supported primarily for MaraDNS users who
already have zone files in the csv1 format. MaraDNS now supports a csv2
zone file format. Note that the csv1 zone file format will continue to
function as long as I am MaraDNS' maintainer.
# SPECIAL CHARACTERS
`|` This delimits fields
`#` This signifies a comment. Lines starting with this are ignored,
otherwise it has no significance
`%` This, in domain names, signifies that the rest of the domain name
should be the name of this zone
`*` This is translated to mean "any host name that otherwise does not
resolve". It must be at the beginning of a domain name.
`\` This is used as an escape character, either to escape octal values
such as '\045' for %, or to escape the '%' character so it has no
special meaning, or to escape the backslash character.
# NOTES ON PROCESSING
All domain-name labels are converted to their lower-case equivalents
before processing is done. This is because domain-name literals in the
database with one or more upper-case letters in them are
case-sensitive. This is my way to resolve RFC1035's desire to both
allow binary domain labels and be case-insensitive.
The file must first have a SOA record, followed by one or more NS
records, followed by other records. The initial NS and SOA records must
be RR for this zone. NS records after any non-NS record must be part of
another zone. The resolution algorithm will not break if non-CNAME
records share records with a CNAME record, but this is not a good idea
to do.
# RR FORMAT
A domain name is a one-letter designation of its type, followed by the
domain name separated by dots, ending with either a % or a trailing
dot. If the domain name does not end with a % or trailing dot, an error
is returned.
# SUPPORTED RR TYPES
MaraDNS only supports the following types of resource records (RRs) in
csv1 files. More resource records types are supported in csv2 zone
files; see **csv2(5)** for details.
```
Letter Type RFC1035 section 3.2.2 value
A A 1
N NS 2
C CNAME 5
S SOA 6
P PTR 12
@ MX 15
T TXT 16
U any determined in third field of line
```
# FORMAT OF SUPPORTED RR TYPES
Here are the formats, shown by letter name:
```
A: Has three fields
field one: the domain name
field two: the ttl for the name in seconds
field three: the ip address, in dotted decimal notation
Example:
Ahost.example.com.|7200|10.1.2.3
```
A records are described with grueling detail in RFC1035. In
short, an A record is an IP address for a given host name.
```
N: Has three fields
field one: the domain name of the record
field two: the ttl for the name in seconds
field three: the domain name this NS points to.
Example:
Nexample.com.|86400|ns.example.com.
```
NS (N here) records are described in RFC1035
```
C: Has three fields
field one: the domain name of the record
field two: the ttl for the name in seconds
field three: the domain this CNAME record points to
Example:
Calias.example.org.|3200|realname.example.org.
```
CNAME (which C is short for) records are described in RFC1035
```
S: Has nine fields
field one: the domain name of the record
field two: the TTL of the record
field three: the origin of the domain. In other words, the name of the
primary name server for the domain.
field four: the email address for this domain (in the RFC822, not
BIND format)
field five: the serial for the domain
field six: the refresh (how often to see updates) for the domain
field seven: the retry (how often to try when down) for the domain
field eight: the expire (how long before the slave gives up) for the
domain
field nine: the minimum (and default) TTL for the domain
Example:
Sexample.net.|86400|%|hostmaster@%|19771108|7200|3600|604800|1800
```
SOA (S here) records are described in RFC1035
```
P: has three fields
field one: the IP we wish to point to (in in-addr.arpa form)
field two: the ttl for the name in seconds
field three: the FQDN for the IP in question
Example:
P3.2.1.10.in-addr.arpa.|86400|ns.example.com.
```
PTR (P here) records, which are used for reverse DNS lookups, are
described in RFC1035. Note that one needs control of the appropriate
in-addr.arpa subdomain to make PTR records visible on the internet at
large.
```
@: has four fields
field one: The host that people send email to
field two: the ttl for this record
field three: The preference for this MX host
field four: The name of this MX host
Example:
@example.com.|86400|10|mail.example.com.
```
MX (@ here) records are described in RFC1035
```
T: has three fields
field one: The host someone wants to get additional information about
field two: the ttl for this record
field three: The desired text. Any data becomes the record up until a
new line is reached. The new line is not part of the TXT
record
Example:
Texample.com.|86400|Example.com: Buy example products online
```
TXT (T here) records are described in RFC1035
```
U: has four fields
field one: The host someone wants a data type normally unsupported by
MaraDNS for
field two: the ttl for this record
field three: The numeric code for this data type (33 for SRV, etc.)
field four: The raw binary data for this data type
Example:
Uexample.com.|3600|40|\010\001\002Kitchen sink data
```
The above example is a "Kitchen Sink" RR (see
draft-ietf-dnsind-kitchen-sink-02.txt) with a "meaning" of 8, a
"coding" of 1, a "subcoding" of 2, and a data string of "Kitchen sink
data". Since this particular data type is not formalized in a RFC at
this time, the most appropriate method of storing this data is by using
the catch-all "unsupported" syntax.
# EXAMPLE CSV1 ZONE FILE
```
# Example CSV1 zone file
# This is what is known as a SOA record. All zone files need to have one
# of these
S%|86400|%|hostmaster@%|19771108|7200|3600|604800|1800
# These are known as authoritative NS records. All zone files need one or
# more of these
N%|86400|ns1.%
N%|86400|ns2.%
# Some IP addresses
Ans1.%|86400|10.0.0.1
Ans2.%|86400|192.168.0.1
A%|86400|10.1.2.3
Amx.%|86400|10.1.2.4
# An 'IN MX' record
@%|86400|10|mx.%
```
# 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/

845
doc/en/md/csv2.md Normal file
View file

File diff suppressed because it is too large Load diff

367
doc/en/md/csv2_txt.md Normal file
View file

@ -0,0 +1,367 @@
# NAME
csv2_txt - Description of txt and raw resource records in the csv2 zone
file
# DESCRIPTION
Due to the complexity of TXT and RAW records, this man page is
dedicated to describing the csv2 format of this RR.
TXT and RAW rrs in MaraDNS' csv2 zone files can store any arbitrary
binary data. Additionally, it is possible to arbitrarily divide up TXT
records in to chunks (chunks, which RFC1035 call "character-string"s,
are described below).
## ASCII AND UTF-8 DATA
If a given TXT field or RAW record contains only ASCII data, creating a
record is easy: Place the full data between single quotes, like this:
```
a.example.com. TXT 'This is some text' ~
```
It is also possible, to place almost any printable ASCII
characters between quotes. The '~' (tilde) character is not allowed
unless csv2_tilde_handling has a value of 0; the '|' (pipe), '#' (hash)
and non-printable ASCII control characters are not allowed in TXT data
if the ~ is used to separate records. If there are any bytes with a
value of 0x80 or more, the data must be UTF-8 encoded Unicode.
For example:
```
b.example.com. TXT 'This is an example UTF-8 character: I ♥ MaraDNS'
```
(If your font does not have this Unicode symbol, it is a heart)
The printable ASCII characters not allowed in quotes are the '
character, the '|' character, the '~' (tilde) character, and the '#'
character. See BACKSLASH ESCAPE SEQUENCES below for information on
adding these characters to TXT or RAW fields.
## UNQUOTED DATA
Note that the record does not have to be quoted. As long as the record
only contains ASCII alphanumeric data, and/or the characters '-', '_',
'+', '%', '!', '^', and '=', the data can be unquoted as follows:
```
c.example.com. TXT This_is_100%_unquoted_text_+symbols!
```
It is also possible to mix quoted and unquoted text, such as
this:
```
d.example.com. TXT This' is a mix 'of_unquoted' and quoted 'text!
```
Which will have its data look like this:
```
This is a mix of_unquoted and quoted text!
```
When mixing quoted and unquoted data, it is important to have all
whitespace *inside* quotes.
## BACKSLASH ESCAPE SEQUENCES
In order to accommodate storing non-UTF-8 high bit characters, the
single quote character, non-printable ASCII control codes, the '|',
'~', and '#' characters, and to permit multi-line TXT/RAW records (with
comments allowed mid-record), the TXT/RAW RR allows backslashes. These
backslashes only have significance *outside* of quoted text; if they
are placed inside single quotes, they are not interpreted and result in
a literal backslash being added to the resource record data.
The following characters can be backslashed:
`'` When backslashed, the adds a literal quote to the resource record.
`whitespace` When any whitespace is backslashed (space, newline, cr,
and tab), this indicates that the record has not ended, and that more
data for this resource will follow. This also allows comments to be
placed in TXT and RAW resource records. What happens is that the
backslash indicates that any whitespace characters (space, tab,
carriage return, and line feed) are to be ignored until the next
non-whitespace character that is not a # (hash). If a # is seen, this
indicates that we ignore any and all characters until the next carriage
return or line feed, and continue to ignore everything until the next
non-whitespace character. See the section on multi-line and commented
records for examples.
`0123` When a number between 0 and 3 is backslashed, this indicates the
beginning of a three-digit octal number.
`x` When an x is backslashed, this indicates the beginning of a
two-digit hexadecimal number. Note that, with the exception of
the single quote, the backslash character is *not* used to remove the
meta-significance of a given character. In particular, unlike other
environments, it is not possible to backslash spaces. Spaces can be
represented either as ' ' in quotes, \x20, or as \040.
Here are some examples of backslashed data. In this example, we see
backslash sequences being used to store non-UTF-8 hi-bit data:
```
e.example.com. TXT \x80\x81\x82\x83 ~
```
This same data can also be created as follows:
```
f.example.com. TXT \200\201\202\203 ~
```
Octal and hex information can be mixed:
```
g.example.com. TXT \200\x81\202\x83 ~
```
Literal single quotes can be placed in resource records:
```
h.example.com. TXT 'perl -e '\''print "A Perl of a TXT record!\n"'\' ~
```
The above example produces this record:
```
perl -e 'print "A Perl of a TXT record!\n"' ~
```
To render the '~' character, use the escape sequence \x7e
(outside of quotes). For example:
```
h1.example.com. TXT 'http://ocf.berkeley.edu/'\x7e'set' ~
```
Produces this record:
```
http://ocf.berkeley.edu/~set
```
To render the '|' character, use the escape sequence \x7c:
```
h2.example.com. TXT 'ls '\x7c' more' ~
```
Produces this record:
```
ls | more
```
To render the '#' character, use the escape sequence \x23:
```
h3.example.com. TXT 'Press '\x23' for customer service' ~
```
Produces this record:
```
Press # for customer service
```
## MULTI-LINE AND COMMENTED RECORDS
By utilizing backslashes followed by comments, it is possible to have
multi-line and commented TXT and RAW records. The following resource
record will span more than one line on an 80-column display:
```
i.example.com. TXT 'Not only did the quick brown fox jump over the lazy dog, but the lazy dog jumped over the cat.' ~
```
Without affecting this resource record, the same data can be
split over multiple lines:
```
j.example.com. TXT 'Not only did the quick brown fox jump '\
'over the lazy dog, but the lazy dog'\
' jumped over the cat.' ~
```
Some points:
* The backslash must be outsize of the quotes (or a literal backslash
will be added to the record)
* The backslash must be present *before* any unquoted white space.
Usually, the backslash is placed immediately after the quote
character.
* Unlike other environments, it does not matter whether or not there
is invisible whitespace after the backslash.
It is also possible to add comments after such a backslash as follows:
```
k.example.com. TXT 'Not only did the quick brown fox jump '\ # The fox
'over the lazy dog, but the lazy dog'\ # The dog
' jumped over the cat.' ~ # The cat
```
Note that, since the third comment is not preceded by a
backslash, this indicates the end of the resource record.
There can also be multiple lines dedicated to comments (and,
optionally, even blank lines) in the middle of TXT and RAW record data:
```
k2.example.com. TXT 'This is some data '\
# Here we have some comments followed by a blank line
# Now we have some more comments,
# followed by the rest of the data
'and this is the rest of the data' ~
```
## MULTIPLE TXT CHUNKS
TXT RRs may be divided up in to multiple "chunks" (RFC1035 calls these
"character-string"s). A single chunk can be anywhere from zero to 255
bytes long. The default is to have one chunk, as follows:
```
o.example.com. TXT 'TXT record with only one chunk' ~
```
It is also possible to have a record with multiple chunks. Chunks
are delimited by an unquoted ';' character:
```
p.example.com. TXT 'This is chunk one';'This is chunk two' ~
```
Or:
```
q.example.com. TXT 'This is chunk one';\ # Our first chunk
This_is_chunk_two;\ # Our second chunk
'This is chunk three' ~ # Our final chunk
```
Quoted ; characters simply add a ; to the record data.
If a single TXT chunk is longer than 255 bytes long, the csv2 parser
will report an error in the zone file: Single TXT chunk too long
In order to resolve this, place unquoted ; characters in the record
data so that each chunk is under 255 octets (bytes or characters) in
length.
It is possible to have zero length chunks:
```
r.example.com. TXT 'chunk one';;'chunk three' ~ # Chunk two zero-length
```
In particular, is is possible to have zero length chunks at the
beginning and end of a TXT record:
```
s.example.com. TXT ;'chunk two'; ~ # Chunks one and three zero-length
```
Do not place semicolons at the beginning nor end of TXT records
unless you wish to have these zero-length chunks.
Chunk support only exists for TXT records. An unquoted ; character will
cause a syntax error in a RAW record.
## RAW RECORDS
With the exception of no support for chunk delimiters, and the addition
of a numeric record type before the record data, the format for RAW
records is identical to text records. For example, if we wish to have a
"Kitchen Sink" RR record, which has the 8-bit binary numbers "16", "1",
and "2", followed by the ASCII string "Kitchen sink+ data", we can
specify this in any of the following manners:
```
t1.example.com. RAW 40 \x10\x01\x02'Kitchen sink'\x2b' data' ~
```
```
t.example.com. RAW 40 \020\001\002Kitchen' sink+ data' ~
```
```
u.example.com. RAW 40 \x10\x01\x02Kitchen\x20sink+\x20data ~
```
```
v.example.com. RAW 40 \x10\001\x02\
'Kitchen sink+ data' ~
```
```
w.example.com. RAW 40 \x10\ # Meaning: 16
\x01\ # Coding: 1
\x02\ # Sub-coding: 2
'Kitchen sink+ data' ~ # Data: 'Kitchen sink+ data'
```
## DKIM RECORDS
DKIM is a format used to store e-mail authentication data via DNS.
MaraDNS can store a 2048-bit RSA DKIM key. Longer keys are not
supported because of the 512-byte limit for traditional DNS packets.
A DKIM record is a long “multi chunk” TXT record; DKIM records are
stored in a special `_domainkey.example.com` record. As per RFC6376
section 3.6.2.2, “Strings in a TXT RR MUST be concatenated together
before use with no intervening whitespace”; a single TXT “chunk” can
only be up to 255 bytes in length, but we need more than 255 bytes to
store a 2048 bit RSA key (6 bits per character, so we need 342
characters to store just the key) and a little more overhead to store
the other bits in our DKIM record. But, it doesn’t matter where we
split the chunks as long as each individual chunk is under 256 bytes in
size.
Here is a real-world DKIM key stored in a MaraDNS zone file:
```
x._domainkey.% +600 TXT 'v=DKIM1; k=rsa; '\
'p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg'\
'KCAQEAuhKjx2Aepa3rllxUEZLgF3x'\
'68SWvZ8pEgnjZvxtqp94Vkra3AUC4C8dRLKf5SvT'\
'xFtIl6pF27jn+M/w2MzYwPFjBgqVf'\
'p2lf7xuKsrus63m0T9Sq958nIt1yuUlLDr71bFs7'\
'ZuZyQid0ciCc2JF5lwHno10cAvuNJ';'y1Q'\
'tFJa+lRJI6/kzY20Hi/ZTzFzctqgqaRZnSoJlTZHf'\
'Oy0uwfmF5ejkJ8xvHbEJp6TEc'\
'30DwsqrjVWSFLnUWYBv7lrAPB9sAHN7fCayhEuORn'\
'Ap+YUhjjMPWyPla1pvTS9h/LTE7g'\
'2d+jR/zOkRpV2Ak/4KpeP9dpsRJEOsPEaWGG1pQXgPw'\
'IDAQAB'
```
# 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/

161
doc/en/md/duende.md Normal file
View file

@ -0,0 +1,161 @@
# NAME
duende - run a child process as a daemon
# DESCRIPTION
**duende** is a tool for users of init systems which require programs
to provide their own daemonization. **duende** is not needed with
systemd and other init systems which can provide daemonization for
network services. **duende** makes a given child process a daemon. The
standard output and standard error of the child process is logged via
syslog() with a priority of LOG_INFO.
# SYSTEMD
**duende** should not be used if one uses systemd` as the init
process. Instead, files like this should be added to
`/etc/systemd/system`
```
# Place this file here:
# /etc/systemd/system/maradns.service
# Then
# systemctl enable maradns
# systemctl start maradns
# To view log
# journalctl -u maradns
[Unit]
After=network-online.target
ConditionPathExists=/usr/local/bin/maradns
Description=MaraDNS
Wants=network-online.target
[Service]
ExecStart=/usr/local/bin/maradns
StandardOutput=journal
TimeoutSec=0
Type=exec
[Install]
WantedBy=multi-user.target
```
When installed with `make install`, MaraDNS will look for systemd
files, and install MaraDNS and Deadwood startup files.
# USAGE
**duende** (--pid=/path/to/file) child_process [ all subsequent
arguments passed on to child ]
# DETAILS
When **duende** is invoked, it spawns two processes. In addition to
spawning the daemonized child process, **duende** also spawns a process
which reads and logs the standard output of the daemonized process. The
parent process stays alive so as to monitor the daemonized process. If
the optional `--pid` argument is supplied, **duende** will write its
PID to the file specified by the argument. It is an error to supply the
`--pid` argument without an equal sign and file name.
**duende** requires a blank directory named `/etc/maradns/logger` to
run.
Should the parent duende process a HUP signal, **duende** will restart
the child process. Should the daemonized or logging process received an
untrapped HUP signal or exit with an exit code of 8, **duende** will
restart the process. Should the daemonized or logging process exit for
any other reason, **duende** will send the logger process a TERM signal
and exit. Should the duende parent process receive a TERM or INT
signal, **duende** sends all of its children TERM signals, then exits.
The duende process must be started as the superuser; this is because
Duende's intended child processes (maradns and zoneserver) need to bind
to privileged ports, and because duende uses a setuid() call to change
the user ID of the logging process to the user with ID 707.
# LOGGING
**duende** uses the syslog() facility to log the standard output of the
program that it invokes. The name of the program (in other words, the
"ident" given to openlog()) is the full path of the first argument
given to **duende**. All messages created by the child process are sent
to syslog() with a priority of LOG_INFO and a "facility" of LOG_DAEMON
(daemon.info in /etc/syslog.conf); since daemon.info messages are not
logged by default in FreeBSD, on FreeBSD systems messages generated by
the child process are logged with a priority of LOG_ALERT and a
"facility" of LOG_DAEMON (daemon.alert in /etc/syslog.conf). Should
duende itself encounter an error, it will send messages to syslog()
with a priority of LOG_ALERT.
For example, suppose one invokes duende thusly:
```
duende /usr/local/sbin/maradns
```
If invoked thusly, duende will log all messages with the "ident"
(program name) of "/usr/local/sbin/maradns". If this is not desired,
invoke duende with something like:
```
export PATH=$PATH:/usr/local/sbin
duende maradns
```
This will log messages with a (more sensible) "ident" of maradns.
Note: If a non-POSIX Bourne shell (such as csh, es, rc, or fish) is
used to invoke MaraDNS, the above syntax needs to be changed.
Also, the directory /etc/maradns/logger, while used by duende, is not
used to store any log messages. That is unless, for some reason, one
configures syslog to store messages there.
# EXAMPLES
Using duende to start maradns, where the mararc file is /etc/mararc.2
```
duende maradns -f /etc/mararc.2
```
Using duende to start zoneserver, where the mararc file is
/etc/mararc.4
```
duende zoneserver -f /etc/mararc.4
```
# BUGS
**Duende** assumes that all of its children are well-behaved, eating
their vegetables, going to bed when told, and terminating when
receiving a TERM signal.
# SEE ALSO
**maradns(8)**, **syslog(3)**
http://www.maradns.org
# 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
Duende and this man page are written by Sam Trenholme. D Richard Felker
III provided some invaluable assistance with the piping code which
**duende** uses.

72
doc/en/md/fetchzone.md Normal file
View file

@ -0,0 +1,72 @@
# NAME
fetchzone - get dns zone from server
# DESCRIPTION
**fetchzone** transfers a user-specified dns zone from a zone server
and displays it in csv2 format on the standard output.
# USAGE
**fetchzone** zone_name zone_server_IP [query_class]
# OPTIONS
**zone_name**
Name of the dns zone to be transferred.
**zone_server_IP**
IP address of dns server
**query_class**
Optional argument which can change the query class from 1 (the default)
to 255. This may be needed for some versions of Bind.
# EXAMPLES
To obtain the zone example.com from the server 192.168.9.8:
```
fetchzone example.com 192.168.9.8
```
To obtain the zone example.org from the server 10.9.8.78 using a query
class of 255:
```
fetchzone example.com 10.9.8.78 255
```
# BUGS
Fetchzone will not correctly output host names with utf-8 characters in
them.
# SEE ALSO
The man pages **maradns(8)** and **csv2(5)**
http://www.maradns.org
# 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

72
doc/en/md/getzone.md Normal file
View file

@ -0,0 +1,72 @@
# NAME
getzone - get dns zone from server
# DESCRIPTION
**getzone** transfers a user-specified dns zone from a zone server and
displays it in csv1 format on the standard output. This program is here
for compatibility with older setups that use getzone to get zone files;
newer setups may wish to consider using the fetchzone tool to obtain
csv2-compatible zone files.
# USAGE
**getzone** zone_name zone_server_IP [query_class]
# OPTIONS
**zone_name**
Name of the dns zone to be transferred.
**zone_server_IP**
IP address of dns server
**query_class**
Optional argument which can change the query class from 1 (the default)
to 255. This may be needed for some versions of Bind.
# EXAMPLES
To obtain the zone example.com from the server 192.168.9.8:
```
getzone example.com 192.168.9.8
```
To obtain the zone example.org from the server 10.9.8.78 using a query
class of 255:
```
getzone example.com 10.9.8.78 255
```
# SEE ALSO
The man pages **maradns(8)** and **csv1(5)**
http://www.maradns.org
# 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
MaraDNS is written by Sam Trenholme. Jaakko Niemi used 5 minutes to put
this manpage together. Sam has subsequently made revisions to this
manpage.

1306
doc/en/md/maradns.md Normal file
View file

File diff suppressed because it is too large Load diff

812
doc/en/md/mararc.md Normal file
View file

File diff suppressed because it is too large Load diff

87
doc/en/md/mqhash.md Normal file
View file

@ -0,0 +1,87 @@
# NAME
mqhash - Simple secure password generator
# SYNOPSIS
**mqhash [-n #] [-s] [-u] {data to hash}**
# DESCRIPTION
**mqhash** is a simple secure password generator.
The program uses MaraDNS' secure random number generator as the
compression function for a secure hash; the output of this secure hash
can be used as passwords for various locations on the internet.
This program solves the problem of either using the same password on
multiple web sites, or having so many passwords that it is not
practical to remember them all.
# USAGE
The first step in using **mqhash** as a secure password generator is to
set up a master secret from which all other passwords are generated. It
is important to keep this master secret secure; such as on a Linux or
BSD machine that is always behind a firewall and is current with
security updates.
This secure secret is put in the file `~/.mhash_prefix`. It is
important that this secret is hard to guess; the security of all
generated passwords is only as secure as the master secret.
Once the `~/.mhash_prefix` file is set up, mqhash is run thusly:
```
mqhash -s {location}
```
Where {location} is a web site, email address, or any other text
string that describes where a given password is located. It is
recommended that one uses a consistent style for {location} so that one
can remember passwords for web sites that one has not visited for a
while. Mqhash does not impose a style for remembering passwords; it is
up to the user to create one.
**mqhash** will output four potential passwords that have 32 bits of
entropy. If more entropy is desired in a password, two 32-bit passwords
can be joined together to generate a 64-bit password. A 32-bit password
will protect against casual attacks but can be broken by a determined
attacker with extensive resources attacking a website that does not
lock out a user after too many failed attempts. A 64-bit password is
immune to even a very determined attacker.
## OPTIONS
`-n` It is wise to periodically change ones password on sites that one
uses frequently. This allows one to continue to have passwords after
the four initial passwords have already been used; this can have a
value between 2 and 9.
`-s` The normal mode for mqhash: To create a secure password based on
both the contents of `~/.mhash_prefix` and the final argument to
mqhash.
`-u` This will generate a cryptographic hash out of the final argument
sent to mqhash. This is useful when one does not need a secure
password, but just wants to hash a short string.
# 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.

90
doc/en/md/zoneserver.md Normal file
View file

@ -0,0 +1,90 @@
# NAME
zoneserver - handle zone transfers and other TCP functions for MaraDNS
# DESCRIPTION
**zoneserver** listens on port 53/tcp and handles DNS zone transfers
and any DNS query done over TCP instead of UDP. **zoneserver** uses a
configuration file, **/etc/mararc** by default, to determine its
parameters.
# USAGE
**zoneserver -f** pointer_to_mararc_file
# OPTIONS
`-f` Specifies the location of the configuration file. MaraDNS uses the
same configuration file for both the main dns server and the
zoneserver.
# CONFIGURATION FILE FORMAT
The file format for the mararc file can be found in the **mararc(5)**
manual page. In particular, the zoneserver uses the zone_transfer_acl,
tcp_convert_acl, tcp_convert_server, and bind_address mararc
parameters.
# EXAMPLE MARARC FILE
In this example mararc file, which is used both by maradns and
zoneserver, we allow 10.1.2.3, 10.1.14.7, and 192.168.116.{any} to
transfer zones, and we allow anyone on the internet to perform TCP
queries. The only zone served in this example is example.com:
```
ipv4_bind_addresses = "10.1.1.1" # Our IP
tcp_convert_server = "10.1.1.1" # IP of UDP DNS server
tcp_convert_acl = "0.0.0.0/0" # Anyone may do DNS-over-TCP
chroot_dir = "/etc/maradns" # Where zone files are
csv2 = {} # Initialize list of zone files
csv2["example.com."] = "db.example.com" # example.com zone file
# The next line is a list of who can transfer zones from us
zone_transfer_acl = "10.1.2.3, 10.1.14.7, 192,168.116.0/24"
```
# SEE ALSO
The man pages **maradns(8)** and **mararc(5)**
http://www.maradns.org
# BUGS
**zoneserver** assumes that the authoritative NS records are
immediately after the SOA record, and that there is at least one non-NS
between that last authority NS record for the zone and the first
delegation NS record.
IXFR requests are incremental zone transfers, meaning that the DNS
server should only display records changed since the last IXFR request.
**zoneserver**, however, treats an IXFR as if it were an AXFR request,
outputting all of the records for the zone in question.
**zoneserver** closes the TCP connection after transferring the
requested zone.
If an unauthorized client attempts to connect to the zoneserver,
**zoneserver** immediately disconnects the unauthorized client.
# 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
MaraDNS is written by Sam Trenholme. Jaakko Niemi used 5 minutes to put
the original version this manpage together. Sam has subsequently
revised this manual page.