Erre con erre cigarro Erre con erre barril Rápido ruedan los carros En el ferrocarril
Name Synopsis Table of Contents Description Usage Firewall Configuration Frequently Asked Questions Bugs Unimplemented Features Legal Disclaimer Authors
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 /usr/local/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
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.
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:
1. How to I try out MaraDNS?2. What license is MaraDNS released under?
3. How do I get MaraDNS to bind to multiple IP addresses?
4. How come BIND 9 can not process MaraDNS queries when MaraDNS is bound to multiple IP addresses?
5. How do I report bugs in MaraDNS?
6. How to 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 Fatal error: Error running populate_main programor a Fatal error: init_cache() failed error message.
10. I am trying to register a domain under the .au or the .de name space,and my registrar is not taking my domain name
11. After I start MaraDNS, I can not see the process when I run netstat -na
12. What string library does MaraDNS use?
13. Why is MaraDNS public domain instead of BSD or GPL licensed?
14. Why does MaraDNS use a multi-threaded model?
15. I feel that XXX feature should be added to MaraDNS
16. I feel that MaraDNS should use another documentation format
17. Is there any process I need to follow to add a patch to MaraDNS?
18. Can MaraDNS act as a primary nameserver?
19. Can MaraDNS act as a secondary nameserver?
20. What is the difference between an authoritative and a recursive DNS server?
21. The getzone client isn't allowing me to add certain hostnames to my zone
22. I have having problems transferring zones from MaraDNS' zone server to a BIND zone transfer client
23. Is MaraDNS portable?
24. How do I compile MaraDNS on OpenBSD?
25. Can I use MaraDNS in Windows?
26. MaraDNS freezes up after being used for a while
27. What kind of Python integration does MaraDNS have
28. Doesn't "kvar" mean "four" in Esperanto?
29. How do I make MaraDNS' time stamps human-readable?
Read the quick start guide, which is the file named 0QuickStart in the MaraDNS distribution.
None, actually. MaraDNS is released to the public domain.
The current method is to run multiple copies of MaraDNS, each using its own mararc file.
E.g:
maradns -f /usr/local/etc/mararc.1 maradns -f /usr/local/etc/mararc.2 etc.
If you just want to bind to all IP addresses your computer has, bind to the IP "0.0.0.0"; however this can cause problems. See the next question.
I don't think this will be too hard to correctly implement, since I already have code for specifying multiple IP addresses with the IP ACL code used by the zone server. Until then, I will add this workaround to the FAQ.
Before reporting a bug that MaraDNS has, please read the relevant man pages. The man pages should be installed when one installs MaraDNS, and, in addition, are available in the doc/man directory of the MaraDNS source tarball. (It is also possible that you are reading the man page right now)
Some MaraDNS man pages (namely, the man pages for maradns, askmara, zoneserver, and mararc) have a section, titled "BUGS", which list already known bugs which I feel are not important enough to fix before the 1.0 release of MaraDNS. Bug reports which mention one of these bugs will be cheerfully ignored (or given a polite "thanks for the report, in this man page the bug is already mentioned" message if I am in a particularly good mood).
Subscribe to the mailing list by sending mail to list-subscribe@maradns.org with "subscribe" as the subject line, and describe the bug by sending email to list@maradns.org.
P4.3.2.1.in-addr.arpa.|86400|www.example.com.
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.timeout_seconds = 5
If a line in a mararc file is too long, you will see, before the "Fatal error: Error running populate_main program" message, a message showing you the line number which is too long and the filename with the offending line. While it is possible to increase this limit by changing the appropriate variable in the MaraDns.h file, the current limit is in line with the 512-byte limit that UDP DNS packets have; MaraDNS does not currently support DNS over TCP.
Otherwise, this error message should not be visible. If it appears, subscribe to the mailing list (see above), and describe your problem by sending email to list@maradns.org. Be sure to include the following information:
Both the German registrar and the Australian registrars require a RR_ANY request to return NS and SOA records. MaraDNS can do this if you add the following line to your mararc file:
default_rrany_set = 15
When MaraDNS is up, the relevant line in the netstat output looks like this: udp 0 0 127.0.0.4:53 0.0.0.0:*
While on the topic of netstat, if you run netstat -nap as root, you can see the names of the processes which are providing internet services.
MaraDNS uses her 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
So that MaraDNS can be integrated with Python without trouble. While Python is, I believe, currently GPL compatible, Python was not GPL-compatible at the time I decided on a license for MaraDNS.
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.
Before sending mail to the list with a feature request, please read the UNIMPLEMENTED FEATURES section of the MaraDNS man page, which has a list of feature requests other people have already sent me. If you do not see your requested feature in this section of the man page, send an email to the mailing list so that I can add your feature request to the UNIMPLEMENTED FEATURES section of the MaraDNS man page.
Feature requests which include a patch which implements the feature in question are may even be implemented by MaraDNS, as long as the patch comes with a declaration that the patch is public domain.
Note that MaraDNS is currently "frozen". In other words, new features will not be added until after the 1.0 release.
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.
For people who prefer other formats of documentation, I am open to making filters which convert from MaraDNS' own "EJ" documentation format to the format in question after MaraDNS 1.0 is released.
Having a given program have its own documentation format is not without precedent; Perl uses its own "pod" documentation format.
Yes.
Here is the procedure for making a proper patch:
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.
Yes.
The 'getzone' program obtains zone files from remote DNS servers, outputting the contents of the zone file in MaraDNS' "csv1" zone file format. This program can be run from cron. If one desires more BIND-like functionality, getzone can be wrapped in a shell script that uses askmara to look at the SOA record to see if the serial number of the zone has changed.
I feel that the traditional DNS design of having a single application both serve DNS records and handle the maintenance of zone files is not ideal; the best design is to have a number of simple applications working together.
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.
P1.1.1.10.in-addr.arpa.|86400|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:
BIND is rather picky about what kind of data it will accept from a zone server. Make sure the following is true with your domain:
Here is an example bad zone file:
Sexample.com.|86400|example.com.|hostmaster@example.com.|1|86400|3600|6048000|86400 Nbad.example.com.|86400|ns1.example.com. Nbad.example.com.|86400|ns2.example.com. Nsubdomain.example.com.|86400|ns.subdomain.example.com. Aexample.com.|12345|10.2.3.4
Here is the same zone file, with corrections:
Sexample.com.|86400|example.com.|hostmaster@example.com.|1|86400|3600|6048000|86400 Nexample.com.|86400|ns1.example.com. Nexample.com.|86400|ns2.example.com. Aexample.com.|12345|10.2.3.4 Nsubdomain.example.com.|86400|ns.subdomain.example.com.
While I intend to have MaraDNS be a portable DNS server which will compile on a variety of unices, right now all of MaraDNS's work development is being done on Linux. In terms of proprietary OSes, I know that SCO Open Server, SCO UNIXware and Solaris have issues running a UDP or TCP server in a chroot() environment. Word is that, with Solaris and UNIXware, placing /dev/tcp and /dev/udp in the chroot() jail will allow a server like MaraDNS to function.
See below for why MaraDNS may have problems as a recursive nameserver in Solaris.
There are two ways to do this:
To use the native thread support add -pthread to the CFLAGS variable.
To use the GNU pthread library, install the pth package and add -L/usr/local/lib/pth to the linker.
(Florin Iucha provided this tip)
Yes.
Provided, of course, that one has the Cygwin environment which emulates a UNIX environment in Windows.
MaraDNS should now compile fine on Cygwin systems. If not, join the mailing list and let me know; I will correct this FAQ entry.
If you still see MaraDNS freeze up after making this correction, please send a bug report to the mailing list.
There is currently no other integration with Python.
To make MaraDNS' time stamps human readable, use this Perl script:
#!/usr/bin/perl -p $| = 1; # Joe Cooper came up with this elegant regular expression s/Timestamp: \d+/localtime/e;This can also be done on the command line when calling maradns as follows:
maradns -f /usr/local/etc/maradns | perl -pe '$|=1; s/Timestamp: \d+/ localtime/e' >> logfileFor people who do not have Perl, awk can do this just as well:
maradns -f /usr/local/etc/maradns | awk ' /Timestamp/{ gsub(/Timestamp: ([0-9]+)/, strftime("%a, %d %b %Y %H:%M:%S",$2),$0)} {print}' >> logfileThe MaraDNS startup script has the option to use this Awk script to convert the time stamp; read the script for details.
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.
When a resolver asks for an A record, and the A record is a CNAME that points to another CNAME (and possibly a longer CNAME chain), while MaraDNS returns the correct IP (as long as the glueless level is not exceeded), MaraDNS will incorrectly state that the first CNAME in the chain directly points to the IP.
If a NS record points to a list of IPs, and the NS record in quesiton is a "glueless" record (MaraDNS had to go back to the root servers to find out the IP of the machine in question), MaraDNS' recursive resolver only uses the first listed IP as a name server.
When MaraDNS' recursive resolver recives a "host not there" reply, instead of using the SOA minimum of the "host not there" reply as the TTL (Look at RFC1034 §4.3.4), MaraDNS uses the TTL of the SOA reply.
MaraDNS keeps referral NS records in the cache for one day instead of the TTL specified by the remote server.
MaraDNS has very limited support for DNS data over TCP. In particular, MaraDNS only uses DNS-over-TCP for zone transfers, which is handled by the companion program zoneserver (see zoneserver(8) for usage information), and only allows authorized IPs to make zone transfer requests.
MaraDNS handles the "any record" (255) request by only returning A and MX records (optionally: NS and SOA records), instead of sending all of the records assosciated with a given host name. The only places where I have seen the "any record" query used is by MTAs, and by the .au and .de registrars. In recursive mode, a request for "any record" is translated in to separate A and MX requests, which MaraDNS subsequently concatenates together.
MaraDNS never returns a NXDOMAIN (nothing in the answer section, SOA in the authority section, result code of "name error" [3]). If a given domain node label does not exist for any RR, MaraDNS will still return a "no host" (nothing in the answer section, SOA in the authority section, 0 result code), implying that the host name exists for at least one RR type.
MaraDNS does not use the zone file ("master file") format specified in chapter 5 of RFC1035.
If a wildcard MX record exists in the form "*.example.com", and there is an A record for "www.example.com", but no MX record for "www.example.com", the correct behavior (based on RFC1034 §4.3.3) is to return "no host" (nothing in the answer section, SOA in the authority section, 0 result code) for a MX request to "www.example.com". Instead, MaraDNS returns the MX record attached to "*.example.com".
Star records (what RFC1034 calls "wildcards") can not be attached to NS records.
MaraDNS' recursive resolver does not perform TTL aging; while MaraDNS will expire a record TTL seconds after adding a record to her cache, the TTL that MaraDNS' recursive resolver displays is always the TTL the authoritative server gave MaraDNS. This means that records will stay in the cache longer than the original domain name owner may desire if one is using upstream or downstream dns servers.
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 does not send more than one DNS packet to a given DNS server when processing a DNS request; this is not a serious problem because most client implenetations send multiple DNS packets to a recurisve DNS server when processing a DNS request.
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.
MaraDNS does not become a daemon. One can use a shell with job control functionality to make MaraDNS a daemon process, e.g:
nohup maradns > /dev/null &
MaraDNS does not use syslog or any other logging facility to log messages that MaraDNS generates. Instead, the messages are logged to standard output. One can use a shell's output redirection to log messages to a file, e.g:
MaraDNS does not have a "fully qualified host name" record, which would automagically create a PTR record from an A record.touch /var/log/maradns nohup maradns >> /var/log/maradns &
MaraDNS does not have support for a "default" zone, which would allow one to add zones without needing to change MaraDNS configuration files.
MaraDNS, like every other known free DNS server implementation, does not have SQL support.
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 does not support IPv6.
MaraDNS has no signal handlers. Sending a HUP signal to MaraDNS terminates the MaraDNS process instead of telling MaraDNS to reload the configuration files.
With the exception of the ability to decompress some RR types not present in RFC1035, MaraDNS does not support any DNS features which are not present in RFC1034 and RFC1035.
MaraDNS, in accordance with RFC1034 §4.3.3, only allows wildcards at the beginning of a host name. E.g. names with wildcards like "foo.*.example.com" or "www.*" will not work.
MaraDNS does not have support for MRTG or any other SNMP-based logging mechanism. In fact, MaraDNS does not even use syslog().
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:
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.
Thomas Seyrat has provided French translations of the MaraDNS documentation.
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.
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.