42
42
<a href="index.html">Main</a>
43
43
<a href="download.html">Download</a>
44
<a href="changelog.html">Changelog</a>
45
44
<a href="notes.html">Documentation</a>
46
<a href="search.html">Search</a>
47
45
<a href="/blog">Blog</a>
48
<a href="security.html">Security</a>
46
<a href="changelog.html">Changelog</a>
47
<a href="sponsors.html">Sponsors</a>
48
<a href="products.html">Products</a>
49
49
</div> <!-- maradns-l -->
50
50
<script type="text/javascript">
216
214
<H2>1. I'm using an older version of MaraDNS</H2>
218
Upgrade to MaraDNS 1.4 or MaraDNS 2.0. MaraDNS 1.4 is compatible with
219
older versions of MaraDNS, with the relatively few changes need to upgrade
216
Upgrade to MaraDNS 1.4. MaraDNS 1.4 is compatible with older versions
217
of MaraDNS, with the relatively few changes need to upgrade
220
218
<A href=http://maradns.org/tutorial/update.html>documented</A>.
224
Use MaraDNS 2.0 if there are any issues using MaraDNS 1.4 to recursively
225
resolve records (via <tt>recursive_acl</tt>); the recursive resolver
226
in MaraDNS 1.4 is deprecated and only critical security issues are fixed
227
with it. MaraDNS 2.0 uses the separate daemon Deadwood to recursively
232
222
MaraDNS 1.0 and 1.2 are only supported for critical security updates, and
233
223
will no longer be supported on December 21, 2010. MaraDNS 1.3 is also only
234
224
supported for critical security updates, and support will stop on December
235
21, 2012. MaraDNS 1.4 and MaraDNS 2.0 are both fully supported (security
236
and other important bug fixes) for the foreseeable future.
225
21, 2012. MaraDNS 1.4 will be fully supported (security and other important
226
bug fixes) for the foreseeable future, alongside MaraDNS 2.0 when and if
341
<H2>8. I am on a slow network, and Deadwood can not process recursive
332
<H2>8. I am on a slow network, and MaraDNS can not process recursive
344
Deadwood, by default, only waits two seconds for a reply from a remote
335
MaraDNS, by default, only waits two seconds for a reply from a remote
345
336
DNS server. This default can be increased by adding a line like this
346
337
in the mararc file:
403
394
<H2>12. Why does MaraDNS use a multi-threaded model?</H2>
405
<p>MaraDNS 2.0 no longer uses threads.
407
<p>The multi-threaded model was the simplest way to write
408
a functioning recursive DNS server for MaraDNS 1.0. There is a reason
409
why MaraDNS, pdnsd, and BIND 9 all use the multi-threaded model.
411
<p>It took me nearly three years to rewrite MaraDNS' recursive resolver
412
as a separate non-threaded daemon. This has been done, and now all recursion
413
is done with Deadwood which does not need threads.
396
<p>The multi-threaded model is, plain and simple, the simplest way to write
397
a functioning recursive DNS server. There is a reason why MaraDNS, pdnsd, and
398
BIND 9 all use the multi-threaded model.
400
<p>MaraDNS 2.0, when and if it is released, will not use threads.
415
402
<A NAME=wishlist>
417
404
<H2>13. I feel that XXX feature should be added to MaraDNS</H2>
419
There are no plans to add new features to MaraDNS or Deadwood at
406
The only thing that will convince me to implement a given feature for
407
MaraDNS is cold, hard cash. If you want me to keep a given feature
408
proprietary, you better have lots of cold hard cash.
410
The only feature I will implement for free is to finish up full
411
recursion in Deadwood, including IPv6 support. I have <A
412
href=http://maradns.blogspot.com/2009/06/why-i-will-not-implement-dns-curve.html>no
413
plans to implement DNS curve</A>, nor <A
414
href=http://maradns.blogspot.com/2009/11/maradns-wish-list-status.html>DNSsec,
415
Geo IP, or whatever feature you want me to implement for fun and for free</A>.
417
Keep in mind that both the BIND and NSD name servers were
418
developed by having the programmers paid to work on the programs.
419
PowerDNS was originally commercial software with the author only
420
reluctantly made GPL after seeing that the market
421
for a commercial DNS server is very small. All of the other DNS servers
422
which have been developed as hobbyist projects (Posadis, Pdnsd, and djbdns)
423
are no longer being actively worked on by the primary developer.
480
484
<p>The <tt>zoneserver</tt> program serves zones so that other DNS servers
481
485
can be secondaries for zones which MaraDNS serves. This is a separate
482
program from the <tt>maradns</tt> server, which processes
483
authoritative UDP DNS queries, and Deadwood which processes recursive
486
program from the <tt>maradns</tt> server, which processes both
487
authoritative and recursive UDP DNS queries.
486
<p>See the <A href="http://www.maradns.org/tutorial/dnsmaster.html">DNS
489
<p>See the <A href="http://www.maradns.org/tutorial/1.2/dnsmaster.html">DNS
487
490
master</A> document in the MaraDNS tutorial for details.
489
492
<A NAME=secondary>
503
507
A recursive DNS server is a DNS server that is able to contact other DNS
504
508
servers in order to resolve a given domain name label. This is the kind
505
of DNS server one points to in <tt>/etc/resolve.conf</tt>. MaraDNS uses
506
the Deadwood daemon to process recursive DNS queries.
509
of DNS server one points to in <tt>/etc/resolve.conf</tt>
510
513
An authoritative DNS server is a DNS server that a recursive server
511
contacts in order to find out the answer to a given DNS query. The
512
maradns daemon processes authoritative DNS queries.
514
contacts in order to find out the answer to a given DNS query.
514
516
<A NAME=bailiwick>
619
621
<h2>26. I am having problems setting <tt>upstream_servers</tt></h2>
621
<tt>upstream_servers</tt> is only supported by Deadwood, and is no
622
longer supported in MaraDNS 2.0.
624
The <tt>upstream_servers</tt> dwood3rc variable is set thusly:
623
The <tt>upstream_servers</tt> mararc variable is set thusly:
627
626
<tt>upstream_servers["."] = "10.3.28.79, 10.2.19.83"</tt>
630
Note the <tt>["."]</tt>.
629
Note the <tt>["."]</tt>. The reason for this is so future versions
630
of MaraDNS may have more fine-grained control over the
631
<tt>upstream_servers</tt> and <tt>root_servers</tt> values.
634
635
Note that the <tt>upstream_servers</tt> variable needs to be initialized
635
636
before being used via <tt>upstream_servers = {}</tt> (the reason for this
636
is so that a dwood3rc file has 100% Python-compatible syntax). A complete
637
dwood3rc file that uses <tt>upstream_servers</tt> may look like this:
637
is so that a mararc file has 100% Python-compatible syntax). A complete
638
mararc file that uses <tt>upstream_servers</tt> may look like this:
640
641
ipv4_bind_addresses = "127.0.0.1"
774
775
<h2>31. I have a NS delegation, and MaraDNS is doing
775
776
strange things.</h2>
777
This is only an issue in MaraDNS 1.4. MaraDNS 2.0 does not allow
778
the same IP to both authoritatively and recursively resolve records.
778
In the case of there being a NS delegation, MaraDNS handles recursive
779
queries and non-recursive DNS queries differently. Basically, unless
780
you use <tt>askmara</tt> with the <tt>-n</tt> option, dig with the
781
<tt>+norecuse</tt> option, or <tt>nslookup</tt> with the <tt>-norec</tt>
782
option, MaraDNS will try to recursively resolve the record that is
787
The thinking is this: A normal recursive DNS query is usually one
788
where one wants to know the final DNS output. So, if MaraDNS
789
delegates a given record to another DNS server, and gets a recursive
790
request for said query, MaraDNS will recursively resolve the query
795
For example, let us suppose we have a <tt>mararc</tt> file that looks
799
chroot_dir = "/etc/maradns"
800
ipv4_bind_addresses = "10.1.2.3"
801
chroot_dir = "/etc/maradns"
802
recursive_acl = "127.0.0.1/8, 10.0.0.0/8"
804
csv2["example.com."] = "db.example.com"
807
And a <tt>db.example.com</tt> file that looks like this:
810
www.example.com. 10.1.2.3
811
joe.example.com. NS ns.joe.example.com.
812
ns.joe.example.com. A 10.1.2.4
815
Next, you are trying to find out why www.joe.example.com is not
816
resolving. If you naively send a query to 10.1.2.3 for www.joe.example.com
817
as <tt>askmara Awww.joe.example.com. 10.1.2.3</tt> or as
818
<tt>dig @10.1.2.3 www.joe.example.com.</tt> or as
819
<tt>nslookup www.joe.example.com. 10.1.2.3</tt>, you will <b>not</b>
820
get any information that will help you solve the problem, since 10.1.2.3
821
will try to contact 10.1.2.4 to resolve www.joe.example.com.
825
The solution is to run your DNS query client thusly:
828
<li>Askmara would be run thusly:
829
<p><tt>askmara -n Awww.joe.example.com. 10.1.2.3</tt><p>
830
<li>Dig would be run thusly:
831
<p><tt>dig +norecurse @10.1.2.3 www.joe.example.com</tt><p>
832
<li>Nslookup would be run thusly:
833
<p><tt>nslookup -norec www.joe.example.com 10.1.2.3</tt><p>
836
This will allow you to see that packets MaraDNS actually sends to
837
a recursive DNS server.
841
As an aside, this particular problem will not happen if MaraDNS is
842
run only as an authoritative nameserver.
780
844
<A name="synthns"> </A>
839
903
<A name=roothints> </A>
840
904
<h2>33. Where is the root.hints file?</h2>
842
MaraDNS (actually, Deadwood), unlike BIND, does not need a complicated
843
root.hints file in order to have custom root servers. In order to change
844
the root.hints file, add something like this to your dwood3rc file:
906
MaraDNS, unlike BIND, does not need a complicated root.hints file in
907
order to have custom root servers. In order to change the root.hints
908
file, add something like this to your mararc file:
847
911
root_servers["."] = "131.161.247.232,"
1049
<li> MaraDNS version 1.4 or 2.0 needs to be used; if you're using an
1115
<li> MaraDNS version 1.4 needs to be used; if you're using an
1050
1116
older version of MaraDNS, upgrade.
1052
<li> It is necessary to have recursion disabled, if using MaraDNS 1.4, either
1053
by compiling MaraDNS without recursive support (./configure --authonly ; make),
1118
<li> It is necessary to have recursion disabled. This can be done either by
1119
compiling MaraDNS without recursive support (./configure --authonly ; make),
1054
1120
or by making sure MaraDNS does not have recursion enabled (by not having
1055
<tt>recursive_acl</tt> set in one's MaraDNS 1.4 mararc file)
1121
<tt>recursive_acl</tt> set in one's mararc file)
1059
If one wishes to both register domains with AFNIC and use MaraDNS 1.4 as a
1125
If one wishes to both register domains with AFNIC and use MaraDNS as a
1060
1126
recursive DNS server, it is required to have the recursive server be a
1061
1127
separate instance of MaraDNS on a separate IP. It is not possible to have
1062
1128
the same DNS server both send DNS packets in a way that both makes AFNIC
1077
1143
<h2>43. I can't see the full answers for subdomains I have delegated</h2>
1079
To have the subdomains be visible to MaraDNS 1.4 recursive nameservers,
1080
add the following to your mararc file:
1145
To have the subdomains be visible to recursive nameservers, add the following
1146
to your mararc file:
1082
1148
<tt>recurse_delegation = 1</tt>
1105
1171
Since the old recursive code is a bit difficult to maintain, and since I
1106
1172
in the process of rewriting the recursive code, my rule is that I will only
1107
resolve security issues with MaraDNS 1.0's recursive resolver.
1173
resolve security issues with MaraDNS 1.0's recursive resolver without
1176
If resolving a given domain with MaraDNS' code is an urgent issue
1177
for you, please consider helping beta-test Deadwood, or sponsoring MaraDNS:
1179
<A href=http://www.maradns.org/products.html>http://www.maradns.org/products.html</A>
1110
1181
<A name=nxdomain2> </A>
1111
1182
<h2>45. MaraDNS 1.2 has issues with NXDOMAINS and case sensitivity.</h2>
added
removed
doc/en/webpage/faq.html
