Read the quick start guide, which is the file named 0QuickStart in the MaraDNS distribution.
None, actually. MaraDNS is relased to the public domain.
The current method is to run multiple copies of MaraDNS, each using its own mararc file.
E.g:
maradns -f /etc/mararc.1
maradns -f /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".
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 relevent man pages. The man pages should be installed when one installs MaraDNS, and, in addition, are availble 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.
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 relevent 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 compatable, Python was not GPL-compatible at the time I decided on a license for MaraDNS.
The multithreaded 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 multithreaded 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.
Yes. Send a patch to me in email, along with a statement that you place the contents of the patch in to the public domain. If I find that the patch works well, I will integrate it in to MaraDNS.
Yes, but not in the same manner as traditional DNS servers.
MaraDNS' philosophy for the 1.0 release is simplicity and security. Since it is simpler to make the programs that handle the getting and serving of zone files separate applications, I have elected to use this approach for the 1.0 release.
I feel that one of UNIX's great strengths is the ability to use a series of small, simple programs together to perform complex tasks. This is the approach I am taking with MaraDNS 1.0.
The "core" of a DNS server ideally is doing little more than the following:
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 suport you have to add -pthread to the CFLAGS.
To use the GNU pthread you need to install the pth package and add -L/usr/local/lib/pth to the linker.
(Florin Iucha provided this tip)
There was a known issue with MaraDNS having memory leaks when used as a recursive nameserver on the Solaris operating system. This problem does not exist in Linux, because Linux's pthread library does not need to use pthread_attr_destroy. Since I do not have ready access to a Solaris box to develop on, I can not verify that my fix resolves this issue. If you are using Solaris, and can verify that the recursive code does not leak memory, please let the mailing list know so I can remove this error message.