~ubuntu-branches/ubuntu/trusty/maradns/trusty-proposed

« back to all changes in this revision

Viewing changes to deadwood-3.0.05/doc/FAQ.ej

  • Committer: Package Import Robot
  • Author(s): Nicholas Bamber
  • Date: 2012-03-14 08:45:48 UTC
  • mfrom: (1.2.9)
  • Revision ID: package-import@ubuntu.com-20120314084548-6slw035p8443a19q
Tags: 1.4.11-1
* New upstream release
* Removed changelog patch
* Added to docs rules to fix missing faq.txt
* Raised standards version to 3.9.3
  - Updated debian/copyright format
  - Removed lintian override
  - Changed working directories from /var/run to /run

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
<HEAD>
2
 
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=utf-8">
3
 
</HEAD>
4
 
<BODY>
5
 
<H1>Deadwood FAQ</H1>
6
 
 
7
 
<h2>What is Deadwood?</h2>
8
 
 
9
 
Deadwood is the recursive DNS daemon (service) for the up and coming
10
 
MaraDNS 2.0.  MaraDNS 2.0 is going to have separate programs for
11
 
authoritative records (maradns) and recursive records (Deadwood).  
12
 
Deadwood is a standalone recursive server that can either be used
13
 
in conjunction with MaraDNS, or by itself.  The program can run
14
 
either in CentOS 5 (and hopefully other Linux and *NIX flavors) or
15
 
in Windows XP (as well as newer Windows releases).
16
 
 
17
 
<p>
18
 
 
19
 
The reason for this rewrite is because I have never been satisfied with
20
 
the recursive resolver in MaraDNS 1.0.  When I designed MaraDNS 1.0's
21
 
recursive resolver, there were a number of things needed to get full
22
 
recursion to work that I did not anticipate.  By the time I shoehorned
23
 
in all of the features needed in a fully recursive DNS server, the code
24
 
was rather messy and difficult to maintain.
25
 
 
26
 
<p>
27
 
 
28
 
Ever since 2002, my plan has been to rewrite MaraDNS' recursive code.  
29
 
In the fall of 2007, I finally started making the code; the code
30
 
became feature complete in the summer of 2010.
31
 
 
32
 
<h2>How do I use Deadwood?</h2>
33
 
 
34
 
Create a configuration file, <tt>/etc/dwood3rc</tt>, that looks like this:
35
 
 
36
 
<pre>
37
 
bind_address="127.0.0.1"
38
 
recursive_acl="127.0.0.1/8"
39
 
chroot_dir="/etc/deadwood"
40
 
</pre>
41
 
 
42
 
Now, create an empty directory owned by root called <tt>/etc/deadwood</tt>.  
43
 
Once this is done, compile Deadwood (as per INSTALL.txt), and see if it runs.  
44
 
The above configuration file will only allow connections using the loopback
45
 
interface on the same machine to resolve domains with Deadwood.
46
 
 
47
 
<h2>How do I convert a MaraDNS mararc file in to a Deadwood dwood3rc file?</h2>
48
 
 
49
 
While some effort has been made to have Deadwood use the same syntax and 
50
 
variables as MaraDNS, there are some differences to keep in mind:
51
 
 
52
 
<ul>
53
 
 
54
 
<li>Deadwood does not have a "ipv4_alias" parameter.  
55
 
 
56
 
<li>Deadwood handles "verbose_level" differently; to get fully verbose
57
 
    messages, "verbose_level" has to be 100 (as opposed to MaraDNS' 10)
58
 
 
59
 
</ul> 
60
 
 
61
 
<h2>I changed a configuration parameter but it has not affected Deadwood</h2>
62
 
 
63
 
Be sure to delete the cache file when making any changes to Deadwood's
64
 
configuration.  In Windows, the cache file is called dw_cache_bin (unless
65
 
the dwood3rc.txt file is edited); in CentOS, with the default dwood3rc file,
66
 
the file is called dw_cache.
67
 
 
68
 
<h2>Deadwood sends out a lot of queries</h2>
69
 
 
70
 
Deadwood will do this on a slow network, since the default parameters are
71
 
tuned to get a fast reply on a broadband internet connection.  On a slow
72
 
(dialup, saturated broadband, etc) connection, timeout_seconds should
73
 
have a value of 7 and num_retries should have a value of 1.  This is
74
 
done by adding the following lines to the dwood3rc file:
75
 
 
76
 
<pre>
77
 
timeout_seconds = 7
78
 
num_retries = 1
79
 
</pre>
80
 
 
81
 
<h2>Steve Gibson's DNS benchmark reports that Deadwood is dropping a lot of 
82
 
    DNS packets</h2>
83
 
 
84
 
After running this tool and carefully looking at Deadwood's replies to 
85
 
Gibson's DNS benchmark tool, I can safely conclude that Gibson's tool is
86
 
buggy and that Deadwood is not dropping the packets being sent to it.
87
 
<p>
88
 
 
89
 
A much better tool to use is Namebench, which correctly shows that Deadwood
90
 
drops very few (if any) DNS packets sent to it.  Namebench is available at
91
 
available at http://code.google.com/p/namebench/
92
 
 
93
 
<h2>Can Deadwood blacklist by domain?</h2>
94
 
 
95
 
Yes.
96
 
<p>
97
 
 
98
 
To blacklist a domain, add a line like this to the dwood3rc file:
99
 
 
100
 
<pre>
101
 
upstream_servers["example.com."] = "192.168.255.255"
102
 
</pre>
103
 
 
104
 
Replace "example.com." with the domain to be blacklisted, and replace 
105
 
"192.168.255.255" with an IP that is either:
106
 
 
107
 
<ul>
108
 
 
109
 
<li>Guaranteed to be unreachable from the server running Deadwood.  In this
110
 
    case, any attempt to reach a blacklisted domain will result in Deadwood
111
 
    timing out and eventually returning a "SERVER FAIL" error message.
112
 
 
113
 
<li>Running a DNS server that always returns the same IP to a given DNS
114
 
    query.  This can be set up by using "csv2_default_zonefile" in MaraDNS,
115
 
    running "microdns" (included in MaraDNS' source tree), or even by running 
116
 
    "nanodns".
117
 
 
118
 
</ul>
119
 
 
120
 
Deadwood uses a hash to store these blacklisted domains, and should be able
121
 
to store thousands of such domains without significant slowdown.
122
 
<p>
123
 
 
124
 
If it is more convenient to store the domains in separate files, this can be
125
 
done using Deadwood's "execfile" mechanism.
126
 
 
127
 
<h2>Does Deadwood have DNSSEC support?</h2>
128
 
 
129
 
No.  I have nothing against DNSSEC per se, but I plain simply am not in a
130
 
position to take the time and effort to implement DNSSEC without being
131
 
compensated for my work.
132
 
 
133
 
</BODY>