1. I'm still using version 1.0 of MaraDNS3. What license is MaraDNS released under?
4. How do I report bugs in MaraDNS?
5. Some of the postings to the mailing list do not talk about MaraDNS!
6. How do I get off the mailing list?
7. How do I set up reverse DNS on MaraDNS?
8. I am on a slow network, and MaraDNS can not process recursive queries
9. When I try to run MaraDNS, I get a cryptic error message.
10. After I start MaraDNS, I can not see the process when I run netstat -na
11. What string library does MaraDNS use?
12. Why does MaraDNS use a multi-threaded model?
13. I feel that XXX feature should be added to MaraDNS
14. I feel that MaraDNS should use another documentation format
15. Is there any process I need to follow to add a patch to MaraDNS?
16. Can MaraDNS act as a primary nameserver?
17. Can MaraDNS act as a secondary nameserver?
18. What is the difference between an authoritative and a recursive DNS server?
19. The getzone client isn't allowing me to add certain hostnames to my zone
21. Can I use MaraDNS in Windows?
22. MaraDNS freezes up after being used for a while
23. What kind of Python integration does MaraDNS have
24. Doesn't "kvar" mean "four" in Esperanto?
26. I am having problems setting upstream_servers
27. Why doesn't the MaraDNS.org web page validate?
29. Does MaraDNS have support for SPF?
30. I'm having problems resolving CNAMES I have set up.
31. I have a NS delegation, and MaraDNS is doing strange things.
33. Where is the root.hints file?
34. Are there any plans to use autoconf to build MaraDNS?
35. How do I change the compiler or compile-time flags with MaraDNS' build process?
36. Will you make a package for the particular Linux distribution I am using?
37. I am using the native Windows port of MaraDNS, and some features are not working.
39. You make a lot of releases of MaraDNS; at our ISP/IT department, updating software is non-trivial.
People who wish to run MaraDNS 1.0 unsupported after 2010/12/21 need to keep in mind that MaraDNS 1.0 is not Y2038 compliant, and will have problems starting in 2036 or so. MaraDNS 1.2, on the other hand, is fully Y2038 compliant.
There is still a FAQ for version 1.0 of MaraDNS available here.
Updating from 1.0 to 1.2 requires a minimum number of changes; with most configurations, MaraDNS 1.2 is fully compatible with MaraDNS 1.0 data files. Details are in the updating document in the tutorial.
While csv1 zone files are fully supported in MaraDNS 1.2, there is a Perl script for updating from CSV1 to CSV2 zone files in the tools/ directory of MaraDNS 1.2.
Read the quick start guide, which is the file named 0QuickStart in the MaraDNS distribution.
Copyright (c) 2002-2007 Sam TrenholmeTERMS
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
This software is provided 'as is' with no guarantees of correctness or fitness for purpose.
This way, people who do not like this can set up mail filters to filter out anything that comes from this list and doesn't have [MARA] in the subject line, or simply unsubscribe from the list and read the list from the archives; if one needs to report a bug, they can subscribe to the list again, post their bug, then unsubscribe after a week.
Another option is to set up one's Freshmeat preferences to be notified in email every time I update MaraDNS at Freshmeat. This will give one email notice of any critical bug fixes without needing to be subscribed to the mailing list.
The web page http://www.maradns.org/ has a link to the mailing list archives.
4.3.2.10.in-addr.arpa. PTR www.example.com. ~
It is also possible, on MaraDNS 1.2.05 and more recent releases, to use a special "FQDN4" which automatically sets up the reverse mapping of a given record:
www.example.com. FQDN6 10.2.3.4 ~If you wish to have a PTR (reverse DNS lookup; getting a DNS name from a numeric IP) record work on the internet at large, it is not a simple matter of just adding a record like this to a MaraDNS zonefile. One also needs control of the appropriate in-addr.arpa. domain.
While it can make logical sense to contact the IP 10.11.12.13 when trying to get the reverse DNS lookup (fully qualified domain name) for a given IP, DNS servers don't do this. DNS server, instead, contact the root DNS servers for a given in-addr.arpa name to get the reverse DNS lookup, just like they do with any other record type.
When an internet service provider is given a block of IPs, they are also given control of the DNS zones which allow them to control reverse DNS lookups for those IPs. While it is possible to obtain a domain and run a DNS server without the knowledge or intervention of an ISP, being able to control reverse DNS lookups for those IPs requires ISP intervention.
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 MaraDNS does return a cryptic error message without letting you know what is wrong, let me know so that I can fix the bug. MaraDNS is designed to be easy to use; cryptic error messages go against this spirit.
When MaraDNS is up, the relevant line in the netstat output looks like this: udp 0 0 127.0.0.1:53 0.0.0.0:*
While on the topic of netstat, if you run netstat -nap as root on Linux and some other *nix operating systems, you can see the names of the processes which are providing internet services.
MaraDNS uses its own string library, which is called the "js_string" library. Man pages for most of the functions in the js_string library are in the folder doc/man of the MaraDNS distribution
The multi-threaded model is, plain and simple, the simplest way to write a functioning recursive DNS server. There is a reason why MaraDNS, pdnsd, and BIND 9 all use the multi-threaded model.
I am planning on improving MaraDNS' threaded model to not spawn a thread for each and every uncached request.
The only thing that will convince me to implement a given feature for MaraDNS is cold, hard cash. If you want me to keep a given feature proprietary, you better have lots of cold hard cash. If you're willing to opensource your feature, less cash should be sufficient.
Keep in mind that both the BIND and NSD name servers were developed by having the programmers paid to work on the programs. PowerDNS was originally commercial software with the author only reluctantly made GPL after seeing that the market for a commercial DNS server is very small. All of the other DNS servers which have been developed as hobbyist projects (Posadis, Pdnsd, and djbdns) are no longer being actively worked on by the primary developer.
My current plans for MaraDNS are visible on the roadmap page for MaraDNS.
If I see a large MaraDNS community and a strong demand for new features from that community, I will consider their wishes. Especially if some of the members of the community have large bank accounts. Should ipv6 start to become dominant, I will update MaraDNS to have full ipv6 support. Should some other technology come along that will require an update to MaraDNS for MaraDNS to continue to function as a DNS server, I may very well update MaraDNS to use that technology.
The reason that MaraDNS uses its own documentation format is to satisfy both the needs of translators to have a unified document format and my own need to use a documentation format that is simple enough to be readily understood and which I can add features on an as needed basis.
The documentation format is essentially simplified HTML with some special tags added to meet MaraDNS' special needs.
This gives me more flexibility to adapt the documentation format to changing needs. For example, when someone pointed out that it's not a good idea to have man pages with hi-bit characters, it was a simple matter to add a new HIBIT tag which allows man pages to be without hi-bit characters, and other document formats to retain hi-bit characters.
Having a given program have its own documentation format is not without precedent; Perl uses its own "pod" documentation format.
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.
See the DNS master document in the MaraDNS tutorial for details.
Yes.
Please read the DNS slave document, which is part of the MaraDNS tutorial.
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.
1.1.1.10.in-addr.arpa. PTR dns.example.com.
MaraDNS will not add the record, since the record is out-of-bailiwick. In other words, it is a host name that does not end in .example.com.
There are two workarounds for this issue:
MaraDNS is developed on a CentOS 3 and Windows XP dual boot laptop. MaraDNS may compile or run on other systems--there are official MaraDNS ports for Debian/Ubuntu, Slackware, FreeBSD, and NetBSD. Note that MaraDNS needs a system with a robust threading library, which some systems do not have.
Yes. There is both a partial mingw32 (native win32 binary) port and a full Cygwin port of MaraDNS; both of these ports are part of the native build of MaraDNS.
If using your ISP's name servers or some other name servers which are not, in fact, root name servers, please make sure that you are using the upstream_servers dictionary variable instead of the root_servers dictionary variable.
If you still see MaraDNS freeze up after making this correction, please send a bug report to the mailing list.
There is currently no other integration with Python.
The "big-O" or "theta" growth rates for various MaraDNS functions are as follows, where N is the number of authoritative host names being served:
Startup time N Memory usage N Processing incoming DNS requests 1
As can be seen, MaraDNS will process 1 or 100000 domains in the same amount of time, once the domain names are loaded in to memory.
upstream_servers["."] = "10.3.28.79, 10.2.19.83"Note the ["."]. The reason for this is so future versions of MaraDNS may have more fine-grained control over the upstream_servers and root_servers values.
Note that the upstream_servers variable needs to be initialized before being used via upstream_servers = {} (the reason for this is so that a mararc file has 100% Python-compatible syntax). A complete mararc file that uses upstream_servers may look like this:
ipv4_bind_addresses = "127.0.0.1"
chroot_dir = "/etc/maradns"
recursive_acl = "127.0.0.1/8"
upstream_servers = {}
upstream_servers["."] = "10.1.2.3, 10.2.4.6"
I have designed MaraDNS' web page to be usable and as attractive as possible in any major browser released in the last ten years. Cross-browser support is more important than strict W3 validation. The reason why the CSS does not validate is because I need a way to make sure there is always a scrollbar on the web page, even if the content is not big enough to merit one; this is to avoid the content jumping from page to page. There is no standard CSS tag that lets me do this. I'm using a non-standard tag to enable this in Gecko (Firefox's rendering engine); this is enabled by default in Trident (Internet Explorer's rendering engine). The standards are deficient and blind adherence to them would result in an inferior web site.
There are also two validation warnings generated by redefinitions which are needed as part of the CSS filters used to make the site attractive on older browsers with limited CSS support.
On a related note, the reason why I use tables instead of CSS for some of the layout is because Microsoft Internet Explorer 6 and other browsers do not have support for the max-width CSS property. Without this property, the web page will not scale down correctly without using tables. Additionally, tables allow a reasonably attractive header in browsers without CSS support.
SPF configuration is beyond the scope of MaraDNS' documentation. However, at the time of this FAQ entry being written (June, 2006), information and documentation concerning SPF is available at http://openspf.org. The BIND examples will work in MaraDNS csv2 zone files as long as the double quotes (") are replaced by single quotes ('). For example, a SPF TXT record that looks like example.net. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" in a BIND zone file will look like example.net. TXT 'v=spf1 +mx a:colo.example.com/28 -all' in a MaraDNS zone file. MaraDNS version 1.2.08 and higher can also make the corresponding SPF record, which will have the syntax example.net. SPF 'v=spf1 +mx a:colo.example.com/28 -all'.
Let us suppose we have a CNAME record without an A record in the local DNS server's database, such as:
google.example.com. CNAME www.google.com. ~
This record, which is a CNAME record for "google.example.com", points to "www.google.com". Some DNS servers will recursively look up www.google.com, and render the above record like this:
google.example.com. CNAME www.google.com. ~ www.google.com. CNAME 66.102.7.104 ~
For security reasons, MaraDNS doesn't do this. Instead, MaraDNS will simply output:
google.example.com. CNAME www.google.com. ~Some stub resolvers will be unable to resolve google.example.com as a consequence.
If you set up MaraDNS to resolve CNAMEs thusly, you will get a warning in your logs about having a dangling CNAME record.
If you want to remove these warnings, add the following to your mararc file:
no_cname_warnings = 1
Information about how to get MaraDNS to resolve dangling CNAME records is in the tutorial file dangling.html
The thinking is this: A normal recursive DNS query is usually one where one wants to know the final DNS output. So, if MaraDNS delegates a given record to another DNS server, and gets a recursive request for said query, MaraDNS will recursively resolve the query for you.
For example, let us suppose we have a mararc file that looks like this:
chroot_dir = "/etc/maradns"
ipv4_bind_addresses = "10.1.2.3"
chroot_dir = "/etc/maradns"
recursive_acl = "127.0.0.1/8, 10.0.0.0/8"
csv2 = {}
csv2["example.com."] = "db.example.com"
And a db.example.com file that looks like this:
www.example.com. 10.1.2.3 ~ joe.example.com. NS ns.joe.example.com. ~ ns.joe.example.com. A 10.1.2.4 ~Next, you are trying to find out why www.joe.example.com is not resolving. If you naively send a query to 10.1.2.3 for www.joe.example.com as askmara Awww.joe.example.com. 10.1.2.3 or as dig @10.1.2.3 www.joe.example.com. or as nslookup www.joe.example.com. 10.1.2.3, you will not get any information that will help you solve the problem, since 10.1.2.3 will try to contact 10.1.2.4 to resolve www.joe.example.com.
The solution is to run your DNS query client thusly:
askmara -n Awww.joe.example.com. 10.1.2.3
dig +norecurse @10.1.2.3 www.joe.example.com
nslookup -norec www.joe.example.com 10.1.2.3
As an aside, this particular problem will not happen if MaraDNS is run only as an authoritative nameserver.
If a zone looks like this:
example.net. +600 soa ns1.example.net. hostmaster@example.net 10 10800 3600 604800 1080 ~ example.net. +600 mx 10 mail.example.net. ~ example.net. +600 a 10.2.3.5 ~ example.net. +600 ns ns1.example.net. ~ example.net. +600 ns ns3.example.net. ~ mail.example.net. +600 a 10.2.3.7 ~ www.example.net. +600 a 10.2.3.11 ~Then the NS records will be "synth-ip" records.
The zone should look like this:
example.net. +600 soa ns1.example.net. hostmaster@example.net 10 10800 3600 604800 1080 ~ example.net. +600 ns ns1.example.net. ~ example.net. +600 ns ns3.example.net. ~ example.net. +600 mx 10 mail.example.net. ~ example.net. +600 a 10.2.3.5 ~ mail.example.net. +600 a 10.2.3.7 ~ www.example.net. +600 a 10.2.3.11 ~This will remove the "synth-ip" records.
To automate this process, this awk script is useful:
fetchzone whatever.zone.foo 10.1.2.3 | awk '
{if($3 ~ /ns/ || $3 ~ /soa/){print}
else{a = a "\n" $0}}
END{print a}' > zonefile.csv2
Replace "whatever.zone.foo" with the name of the zone you are
fetchin 10.1.2.3 with the IP address of the DNS master, and
zonefile.csv2 with the name of the zone file MaraDNS loads.
root_servers["."] = "131.161.247.232," root_servers["."] += "208.185.249.250," root_servers["."] += "66.227.42.140," root_servers["."] += "66.227.42.149," root_servers["."] += "65.243.92.254"Note that there is no "+=" in the first line, and the last line does not have a comma at the end. Read the recursive tutorial document for more information.
In more detail, MaraDNS does not use autoconf for the following reasons:
There are MaraDNS packages for a number of different distributions of Linux and other operating systems. On the MaraDNS site, there is a MaraDNS package for CentOS/Red Hat Enterprise Linux available. There is also usually an up-to-date Slackware package available. In addition, there is a Debian package in the Debian packages collection, a FreeBSD port of MaraDNS, a Ubuntu package which is derived from the Debian package, and undoubtably other MaraDNS packages floating around the internet.
If you wish to have a package for your particular version of Linux (or MacOS X or BSD or...), you can use one of the above packages as a starting point for making your package. For example, other RPM-based distributions can use the CentOS RPM package as a baseline (the .spec file is in the build/ directory). I can not help you with any problems you may encounter making this package since I do not have your particular version of Linux installed on my computer.
As an aside, some of the MaraDNS packages floating around on the internet are out of date (*cough*, Debian, *cough*)1. Please make sure, that if you get a third-party package from the internet, the package is for either MaraDNS 1.0.41, MaraDNS 1.2.12.08, or MaraDNS 1.3.07.05. Older versions of MaraDNS are not supported.
Footnote 1: Debian has a somewhat silly policy that, once a package is declared "stable", they will basically not update it unless there is a Bugtraq security advisory for the package in question. This policy is a good policy for programs made by pimply-faced 16-year-olds who don't know how to manage a release cycle nor a bugfix-only branch, but doesn't make sense for MaraDNS. As I write this, the Debian's "stable" version of MaraDNS is 1.2.12.04, which is about a year behind in terms of bugfixes. I, annoyingly enough, get bug reports from Debian users telling me about bugs I have already fixed in the 1.2 branch of MaraDNS.
Now, to be fair to Debian, their policies do allow me to backport bugfixes to the 1.2.12.04 release of MaraDNS, and the patches do get reviewed by somone else, which minimizes bugfixes introducing new bugs (Yes, I have done that), but there are not enough volunteers to review all of the bugfixes I have made since 1.2.12.04. So, Debian users get stuck with an old, buggy version of MaraDNS. The policy would work if there were enough volunteers to actually review all of my post-1.2.12.04 bugfixes, but the people who created the policy did not take in to account the logistics of volunteer work.
There were only three updates to the 1.0 legacy branch in 2006, and (so far) only two updates to the 1.0 branch in 2007. The 1.2 branch was updated frequently in the first half of 2006, since I felt MaraDNS 1.2 needed some features that didn't make it in to 1.2.00. During this update cycle, there was always a stable bugfix-only branch of MaraDNS.
In August of 2006, I stabilized the 1.2 branch and only five updates have been done since then. Unless there is a critical bug, I only will update the 1.2 branch approximately once every six months or so.
I go to a great deal of effort to make sure MaraDNS releases are as painless to update as possible. I ensure configuration file format compatibility, even between major versions of MaraDNS. With the exception of configuration file parser bugfixes, MaraDNS 1.0 configuration files are compatible with MaraDNS 1.2 and 1.3.
It is impossible to make code that is bug-free or without security problems. This is especially true with code that runs on the public internet.1 Code has to be updated from time to time. What I do in order to minimize the disruption caused by an update is to always have a stable bugfix-only branch of MaraDNS (right now I have three bugfix-only branches), and to, as much as possible, evenly space out the bugfix updates.
Footnote 1: Even DJB's code has security problems. Both Qmail and DjbDNS have known security problems, and need to be patched before put on a public internet server.