2
<TH>DEADWOOD 1 "August 2009" DEADWOOD "Deadwood reference"</TH>
3
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=utf-8">
8
Deadwood - A fully recursive caching DNS resolver
11
Deadwood is a fully recursive DNS cache. This is a DNS server with
12
the following features:
16
<li>Full support for both DNS recursion and DNS forwarding caching
18
<li>Small size and memory footprint suitable for embedded systems
20
<li>Simple and clean codebase
24
<li>Spoof protection: Strong cryptography used to determine the Query ID
27
<li>Ability to read and write the cache to a file
29
<li>Dynamic cache that deletes entries not recently used
31
<li>Ability to use expired entries in the cache when it is impossible to
32
contact upstream DNS servers.
34
<li>IPv6 support can be compiled in if desired
36
<li>Both DNS-over-UDP and DNS-over-TCP are handled by the same daemon
38
<li>Built-in dnswall functionality
42
<h1>COMMAND LINE ARGUMENTS</h1>
44
Deadwood has a single optional command line argument: The location
45
of the configuration file that Deadwood uses, specified with the "-f" flag.
46
If this is not defined, Deadwood uses the file "/etc/dwood3rc" as the
51
In other words, invoking Deadwood as <b>Deadwood</b> will cause Deadwood to
52
use /etc/dwood3rc as the configuration file; invoking Deadwood as
53
<b>Deadwood -f foobar</b> will cause Deadwood to use the file "foobar"
54
in the current working directory (the directory one is in when
55
starting Deadwood) as the configuration file.
57
<h1>CONFIGURATION FILE FORMAT</h1>
59
The Deadwood configuration file is modeled after Python 2's syntax. Any
60
valid Deadwood configuration file should also correctly parse in both
61
Python 2.4.3 and Python 2.6.6. If any configuration file does correctly
62
parse in Deadwood but raises a syntax error in Python, this is a bug that
67
This in mind, whitespace is significant; Deadwood parameters must be in
68
the leftmost column with no leading whitespace. This is a valid line
69
(as long as there are no spaces to its left):
72
recursive_acl = "127.0.0.1/16"
75
The following line, however, will raise a parse error:
78
recursive_acl = "127.0.0.1/16"
81
Observe the space to the left of the "recusive_acl" string in the incorrectly
84
<h1>PARAMETER TYPES</h1>
86
Deadwood has three different parameter types:
90
<li>Numeric parameters. Numeric parameters must not be surrounded
91
by quotes, such as this example:
97
If a numeric parameter is surrounded by quotes, the error message
98
"Unknown dwood3rc string parameter" will appear.
100
<li>String parameters. String parameters must be surrounded by quotes,
101
such as in this example:
104
bind_address = "127.0.0.1"
107
<li>Dictionary parameters. All dictionary parameters must be initialized
108
before use, and dictionary parameters must have both the
109
dictionary index and the value for said index surrounded by quotes,
110
such as in this example:
113
upstream_servers = {}
114
upstream_servers["."]="8.8.8.8, 8.8.4.4"
119
All dwood3rc parameters <i>except</i> the following are
123
<li>bind_address (string)
124
<li>cache_file (string)
125
<li>chroot_dir (string)
126
<li>ip_blacklist (string)
127
<li>ipv4_bind_addresses (string)
128
<li>random_seed_file (string)
129
<li>recursive_acl (string)
130
<li>root_servers (dictionary)
131
<li>upstream_servers (dictionary)
134
<H1>SUPPORTED PARAMETERS</H1>
136
The Deadwood configuration file supports the following parameters:
138
<h2>bind_address</h2>
139
This is the IP (or possibly IPv6) address we bind to.
142
This is the filename of the file used for reading and
143
writing the cache to disk; this string can have lowercase letters,
144
the '-' symbol, the '_' symbol, and the '/' symbol (for putting
145
the cache in a subdirectory). All other symbols become a '_'
150
This file is read and written as the user Deadwood runs as.
153
This is the directory the program will run from.
156
This affects behavior in Deadwood 2.3, but has no effect in Deadwood 3.
157
This variable is only here so Deadwood 2 rc files can run in Deadwood 3.
160
This is the port Deadwood binds to and listens on for
161
incoming connections. The default value for this is the standard DNS port:
164
<h2>filter_rfc1918</h2>
165
When this has a value of 1, a number of different IP ranges are not allowed
166
to be in DNS A replies:
178
If one of the above IPs is detected in a DNS reply, and filter_rfc1918 has
179
a value of 1, Deadwood will return a synthetic "this host does not reply"
180
response (a SOA record in the NS section) instead of the A record.
184
The reason for this is to provide a "dnswall" that protects users for some
185
kinds of attacks, as described at http://crypto.stanford.edu/dns/
189
Please note that Deadwood only provides IPv4 "dnswall" functionality and
190
does not help protect against IPv6 answers. If protection against certain
191
IPv6 AAAA records is needed, either disable all AAAA answers by setting
192
reject_aaaa to have a value of 1, or use an external program to filter
193
undesired IPv4 answers (such as the dnswall program).
196
The default value for this is 1
198
<h2>handle_noreply</h2>
199
When this is set to 0, Deadwood sends no reply
200
back to the client (when the client is a TCP client, Deadwood closes the
201
TCP connection) when a UDP query is sent upstream and the upstream DNS
204
When this is set to 1, Deadwood sends a SERVER FAIL
205
back to the client when a UDP query is sent upstream and the upstream DNS
208
The default value for this is 1
210
<h2>handle_overload</h2>
211
When this has a value of 0, Deadwood sends no reply when a UDP query is
212
sent and the server is overloaded (has too many pending connections);
213
when it has a value of 1, Deadwood sends a SERVER FAIL packet back to
214
the sender of the UDP query. The default value for this is 1.
216
<h2>hash_magic_number</h2>
217
This used to be used for Deadwood's internal hash generator to keep
218
the hash generator somewhat random and immune to certain types of attacks.
219
In Deadwood 3.0, entropy for the hash function is created by looking
220
at the contents of /dev/urandom (secret.txt on Windows machines) and the
221
current timestamp. This parameter is only here so older configuration
222
files do not break in Deadwood 3.0.
224
<h2>ip_blacklist</h2>
225
This is a list of IPs that we do not allow to be in the answer to a
226
DNS request. The reason for this is to counteract the practice some
227
ISPs have of converting a "this site does not exist" DNS answer in to
228
a page controlled by the ISP; this results in possible security issues.
230
This parameter only accepts individual IPs, and does not use netmasks.
233
The user-id Deadwood runs as. This can be any number
234
between 10 and 65535; the default value is 99 (nobody on
235
RedHat-derived Linux distributions). This value is not
236
used on Windows systems.
239
The group-id Deadwood runs as. This can be any
240
number between 10 and 65535; the default value is 99. This
241
value is not used on Windows systems.
243
<h2>max_ar_chain</h2>
244
Whether resource record rotation is enabled. If this has a value
245
of 1, resource record rotation is enabled, otherwise resource record
246
rotation is disabled.
250
Resource record rotation is usually desirable, since it allows DNS to
251
act like a crude load balancer. However, on heavily loaded systems it
252
may be desirable to disable it to reduce CPU usage.
256
The reason for the unusual name for this variable is to retain compatibility
257
with MaraDNS mararc files.
261
The default value is 1: Resource record rotation enabled.
263
<h2>max_inflights</h2>
264
The maximum number of simultaneous clients we process at the same
265
time for the same query.
268
If, while processing a query for, say, "example.com.", another
269
DNS client sends to Deadwood another query for example.com, instead
270
of creating a new query to process example.com, Deadwood will
271
attach the new client to the same query that is already "in flight", and
272
send a reply to both clients once we have an answer for example.com.
275
This is the number of simultaneous clients a given query can have. If this
276
limit is exceeded, subsequents clients with the same query are refused until
277
an answer is found. If this has a value of 1, we do not merge multiple
278
requests for the same query, but give each request its own connection.
282
The default value is 8.
285
The maximum amount of time we will keep an entry in the cache, in seconds.
289
This is the longest we will keep an entry cached. The default value for
290
this parameter is 86400 (one day); the minimum value is 300 (5 minutes) and
291
the maximum value this can have is 7776000 (90 days).
295
The reason why this parameter is here is to protect Deadwood from attacks
296
which exploit there being stale data in the cache, such as the
297
"Ghost Domain Names" attack.
299
<h2>maximum_cache_elements</h2>
300
The maximum number of elements our cache
301
is allowed to have. This is a number between 32 and 16,777,216;
302
the default value for this is 1024. Note that, if writing the
303
cache to disk or reading the cache from disk, higher values of
304
this will slow down cache reading/writing.
308
The amount of memory each cache entry uses is variable depending on the
309
operating system used and the size of memory allocation pages assigned.
310
In Windows XP, for example, each entry uses approximately four kilobytes
311
of memory and Deadwood has an overhead of approximately 512 kilobytes.
312
So, if there are 512 cache elements, Deadwood uses approximately 2.5
313
megabytes of memory, and if there are 1024 cache elements, Deadwood uses
314
approximately 4.5 megabytes of memory. Again, these numbers are for
315
Windows XP and other operating systems will have different memory allocation
320
Please note that each root_servers and upstream_servers
321
entry takes up space in Deadwood's cache and that maximum_cache_elements
322
will need to be increased to store a large number of these entries.
325
This is the maximum number of pending remote UDP connections
326
Deadwood can have. The default value for this is 32.
328
<h2>max_tcp_procs</h2>
329
This is the number of allowed open TCP connections. Default value: 8
332
The number of times we retry to send a query upstream
333
before giving up. If this is 0, we only try once; if this is 1,
334
we try twice, and so on, up to 32 retries. Note that each retry
335
takes timeout_seconds seconds before we retry again. Default
338
<h2>ns_glueless_type</h2>
339
The RR type we send to resolve glueless records. This should be
340
1 (A) when mainly using IPv4 to resolve records. If glueless NS records
341
have AAAA but not A records, and IPv6 is enabled, it may make sense to
342
give this a value of 255 (ANY). If IPv4 ever stops being used on a large
343
scale, it may eventually become possible to make this have a value of
346
The default value is 1: An A (IPv4 IP) record. This parameter has <b>not</b>
347
been tested; use at your own risk.
349
<h2>random_seed_file</h2>
350
This is a file that contains random numbers, and
351
is used as a seed for the cryptographically strong random number generator.
352
Deadwood will try to read 256 bytes from this file (the RNG Deadwood uses can
353
accept a stream of any arbitrary length).
356
Note that the hash compression function obtains some of its entropy before
357
parsing the mararc file, and is hard-coded to get entropy from /dev/urandom
358
(secret.txt on Windows systems). Most other entropy used by Deadwood
359
comes from the file pointed to by random_seed_file.
361
<h2>recurse_min_bind_port</h2>
362
The lowest numbered port Deadwood is
363
allowed to bind to; this is a random port number used for the source
364
port of outgoing queries, and is not 53 (see dns_port above). This
365
is a number between 1025 and 32767, and has a default value of 15000.
366
This is used to make DNS spoofing attacks more difficult.
368
<h2>recurse_number_ports</h2>
369
The number of ports Deadwood binds to for the source port for
370
outgoing connections; this is a power of 2 between 256 and 32768.
371
This is used to make DNS spoofing attacks more difficult. The default
374
<h2>recursive_acl</h2>
375
This is a list of who is allowed to use Deadwood to perform DNS recursion,
376
in "ip/mask" format. Mask must be a number between
377
0 and 32 (for IPv6, between 0 and 128). For example, "127.0.0.1/8"
378
allows local connections.
381
If this has a value of 1, a bogus SOA "not there" reply is sent whenever
382
an AAAA query is sent to Deadwood. In other words, every time a program asks
383
Deadwood for an IPv6 IP address, instead of trying to process the request,
384
when this is set to 1, Deadwood pretends the host name in question does not
385
have an IPv6 address.
388
This is useful for people who aren't using IPv6 but use applications (usually
389
*NIX command like applications like "telnet") which slow things down trying
390
to find an IPv6 address.
393
This has a default value of 0. In other words, AAAA queries are processed
394
normally unless this is set.
398
When this has the default value of 1, MX queries are silently dropped
399
with their IP logged. A MX query is a query that is only done by a
400
machine if it wishes to be its own mail server sending mail to machines
401
on the internet. This is a query an average desktop machine (including
402
one that uses Outlook or another mail user agent to read and send email)
406
Most likely, if a machine is trying to make a MX query, the machine is
407
being controlled by a remote source to send out undesired "spam" email.
408
This in mind, Deadwood will not allow MX queries to be made unless
409
reject_mx is explicitly set with a value of 0.
412
Before disabling this, please keep in mind that Deadwood is optimized
413
to be used for web surfing, not as a DNS server for a mail hub.
414
In particular, the IPs for MX records are removed from Deadwood's
415
replies and Deadwood needs to perform additional DNS queries to get the
416
IPs corresponding to MX records, and Deadwood's testing is more geared
417
for web surfing (almost 100% A record lookup) and not for mail delivery
418
(extensive MX record lookup).
421
If this has a value of 1, a bogus SOA "not there" reply is sent whenever
422
a PTR query is sent to Deadwood. In other words, every time a program asks
423
Deadwood for "reverse DNS lookup" -- the hostname for a given IP address --
424
instead of trying to process the request, when this is set to 1, Deadwood
425
pretends the IP address in question does not have a hostname.
428
This is useful for people who are getting slow DNS timeouts when trying
429
to perform a reverse DNS lookups on IPs.
432
This has a default value of 0. In other words, PTR queries are processed
433
normally unless this is set.
435
<h2>resurrections</h2>
436
If this is set to 1, Deadwood will try to send an
437
expired record to the user before giving up. If it is 0, we
438
don't. Default value: 1
440
<h2>root_servers</h2>
441
This is a list of root servers; its syntax is identical to
442
upstream_servers (see below). This is the type of DNS service
443
ICANN, for example, runs. These are servers used that do
444
not give us complete answers to DNS questions, but merely tell
445
us which DNS servers to connect to to get an answer closer to
450
Please note that each root_servers entry takes up space in Deadwood's
451
cache and that maximum_cache_elements will need to be increased to store
452
a large number of these entries.
455
In order to enable DNS-over-TCP, this variable must be set and have
456
a value of 1. Default value: 0
458
<h2>timeout_seconds</h2>
459
This is how long Deadwood will wait before giving
460
up and discarding a pending UDP DNS reply.
461
The default value for this is 1, as in 1 second, unless Deadwood was
462
compiled with FALLBACK_TIME enabled.
464
<h2>timeout_seconds_tcp</h2>
465
How long to wait on an idle TCP connection before
466
dropping it. The default value for this is 4, as in 4 seconds.
470
Whether TTL aging is enabled; whether entries in the cache have their
471
TTLs set to be the amount of time the entries have left in the cache.
474
If this has a value of 1, TTL entries are aged. Otherwise, they are not.
475
The default value for this is 1.
477
<h2>upstream_port</h2>
478
This is the port Deadwood uses to connect or send packets to the
479
upstream servers. The default value for this is 53; the standard
482
<h2>upstream_servers</h2>
483
This is a list of DNS servers that the load balancer will try to contact.
484
This is a <i>dictionary variable</i> (array indexed by a string instead of
485
by a number) instead of a simple variable. Since upstream_servers
486
is a dictionary variable, it needs to be initialized before being used.
489
Deadwood will look at the name of the host that it is trying to find
490
the upstream server for, and will match against the longest suffix it
494
For example, if someone sends a query for "www.foo.example.com" to
495
Deadwood, Deadwood will first see if there is an upstream_servers
496
variable for "www.foo.example.com.", then look for "foo.example.com.",
497
then look for "example.com.", then "com.", and finally ".".
500
Here is an example of upstream_servers:
503
upstream_servers = {} # Initialize dictionary variable
504
upstream_servers["foo.example.com."] = "192.168.42.1"
505
upstream_servers["example.com."] = "192.168.99.254"
506
upstream_servers["."] = "10.1.2.3, 10.1.2.4"
509
In this example, anything ending in "foo.example.com" is resolved
510
by the DNS server at 192.168.42.1; anything else ending in "example.com"
511
is resolved by 192.168.99.254; and anything not ending in "example.com"
512
is resolved by either 10.1.2.3 or 10.1.2.4.
516
<b>Important:</b> the domain name upstream_servers points to must end in
517
a "." character. This is OK:
520
upstream_servers["example.com."] = "192.168.42.1"
523
But this is <b>not</b> OK:
526
upstream_servers["example.com"] = "192.168.42.1"
529
The reason for this is because BIND engages in unexpected behavior
530
when a host name doesn't end in a dot, and by forcing a dot at the end
531
of a hostname, Deadwood doesn't have to guess whether the user wants
532
BIND's behavior or the "normal" behavior.
535
If neither root_servers nor upstream_servers are set, Deadwood sets
536
root_servers to use the default ICANN root servers, as follows:
540
198.41.0.4 a.root-servers.net (VeriSign)
541
192.228.79.201 b.root-servers.net (ISI)
542
192.33.4.12 c.root-servers.net (Cogent)
543
199.7.91.13 d.root-servers.net (UMaryland)
544
192.203.230.10 e.root-servers.net (NASA Ames)
545
192.5.5.241 f.root-servers.net (ISC)
546
192.112.36.4 g.root-servers.net (DOD NIC)
547
128.63.2.53 h.root-servers.net (ArmyRU)
548
192.36.148.17 i.root-servers.net (NORDUnet)
549
192.58.128.30 j.root-servers.net (VeriSign)
550
193.0.14.129 k.root-servers.net (Reseaux)
551
199.7.83.42 l.root-servers.net (IANA)
552
202.12.27.33 m.root-servers.net (WIDE)
555
This list is current as of May 3, 2010, and was last changed on
560
Please note that each upstream_servers entry takes up space in Deadwood's
561
cache and that maximum_cache_elements will need to be increased to store
562
a large number of these entries.
564
<h2>verbose_level</h2>
565
This determines how many messages are logged on standard output; larger
566
values log more messages. The default value for this is 3.
568
<h1>ip/mask format of IPs</h1>
569
Deadwood uses a standard ip/netmask formats to specify IPs.
570
An ip is in dotted-decimal format, e.g. "10.1.2.3" (or in IPv6
571
format when IPv6 support is compiled in).
574
The netmask is used to specify a range of IPs.
575
The netmask is a single number between
576
1 and 32 (128 when IPv6 support is compiled in), which indicates the
577
number of leading "1" bits in the netmask.
580
<b>10.1.1.1/24</b> indicates that any ip from 10.1.1.0 to 10.1.1.255
584
<b>10.2.3.4/16</b> indicates that any ip from 10.2.0.0 to 10.2.255.255
588
<b>127.0.0.0/8</b> indicates that any ip with "127" as the first
589
octet (number) will match.
592
The netmask is optional, and, if not present, indicates that only
593
a single IP will match.
595
<h1>DNS over TCP</h1>
596
DNS-over-TCP needs to be explicitly enabled by setting tcp_listen to 1.
600
Deadwood extracts useful information from UDP DNS packets marked truncated
601
which almost always removes the need to have DNS-over-TCP. However,
602
Deadwood does not cache DNS packets larger than 512 bytes in size that
603
need to be sent using TCP. In addition, DNS-over-TCP packets which are
604
"incomplete" DNS replies (replies which a stub resolver can not use,
605
which can be either a NS referral or an incomplete CNAME reply) are not
606
handled correctly by Deadwood.
610
Deadwood has support for both DNS-over-UDP and DNS-over-TCP; the same
611
daemon listens on both the UDP and TCP DNS port.
614
Only UDP DNS queries are cached. Deadwood does not support caching
615
over TCP; it handles TCP to resolve the rare truncated reply without any
616
useful information or to work with very uncommon non-RFC-compliant TCP-only
617
DNS resolvers. In the real world, DNS-over-TCP is almost never used.
619
<h1>Parsing other files</h1>
621
It is possible to have Deadwood, while parsing the dwood3rc file, read
622
other files and parse them as if they were dwood3rc files.
625
This is done using <b>execfile</b>. To use execfile, place a line like
626
this in the dwood3rc file:
629
execfile("path/to/filename")
632
Where path/to/filename is the path to the file to be parsed like a
636
All files must be in or under the directory /etc/deadwood/execfile.
637
Filenames can only have lower-case letters and the underscore
638
character ("_"). Absolute paths are not allowed as the argument to
639
execfile; the filename can not start with a slash ("/") character.
642
If there is a parse error in the file pointed to by execfile, Deadwood
643
will report the error as being on the line with the execfile command in
644
the main dwood3rc file. To find where a parse error is in the sub-file,
645
use something like "Deadwood -f /etc/deadwood/execfile/filename"
646
to find the parse error in the offending file, where "filename" is the file
647
to to parsed via execfile.
649
<h1>IPV6 support</h1>
651
This server can also be optionally compiled to have IPv6 support. In order
652
to enable IPv6 support, add '-DIPV6' to the compile-time flags. For
653
example, to compile this to make a small binary, and to have IPv6 support:
656
export FLAGS='-Os -DIPV6'
662
Deadwood is a program written with security in mind.
665
In addition to use a buffer-overflow resistant string library and a coding
666
style and SQA process that checks for buffer overflows and memory leaks,
667
Deadwood uses a strong pseudo-random number generator (The 32-bit version
668
of RadioGatun) to generate both the query ID and source port. For the
669
random number generator to be secure, Deadwood needs a good source of
670
entropy; by default Deadwood will use /dev/urandom to get this entropy.
671
If you are on a system without /dev/urandom support, it is important
672
to make sure that Deadwood has a good source of entropy so that the query
673
ID and source port are hard to guess (otherwise it is possible to forge
678
The Windows port of Deadwood includes a program called
679
"mkSecretTxt.exe" that creates a 64-byte (512 bit) random file called
680
"secret.txt" that can be used by Deadwood (via the "random_seed_file"
681
parameter); Deadwood also gets entropy from the timestamp
682
when Deadwood is started and Deadwood's process ID number, so it is
683
same to use the same static secret.txt file as the random_seed_file
684
for multiple invocations of Deadwood.
688
Note that Deadwood is not protected from someone on the same network viewing
689
packets sent by Deadwood and sending forged packets as a reply.
693
To protect Deadwood from certain possible denial-of-service attacks, it is
694
best if Deadwood's prime number used for hashing elements in the cache is
695
a random 31-bit prime number. The program RandomPrime.c generates a
696
random prime that is placed in the file DwRandPrime.h that is regenerated
697
whenever either the program is compiled or things are cleaned up with
698
make clean. This program uses /dev/urandom for its entropy; the file
699
DwRandPrime.h will not be regenerated on systems without /dev/urandom.
703
On systems without direct /dev/urandom support, it is suggested to see if
704
there is a possible way to give the system a working /dev/urandom. This
705
way, when Deadwood is compiled, the hash magic number will be suitably
710
If using a precompiled binary of Deadwood, please ensure that the system
711
has /dev/urandom support (on Windows system, please ensure that the
712
file with the name secret.txt is generated by the included mkSecretTxt.exe
713
program); Deadwood, at runtime, uses /dev/urandom (secret.txt in Windows)
714
as a hardcoded path to get entropy (along with the timestamp) for the
717
<h1>DAEMONIZATION</h1>
719
Deadwood does not have any built-in daemonization facilities; this is
720
handled by the external program Duende or any other daemonizer.
722
<h1>Example configuration file</h1>
724
Here is an example dwood3rc configuration file:
727
# This is an example deadwood rc file
728
# Note that comments are started by the hash symbol
730
bind_address="127.0.0.1" # IP we bind to
732
# The following line is disabled by being commented out
733
#bind_address="::1" # We have optional IPv6 support
735
# Directory we run program from (not used in Win32)
736
chroot_dir = "/etc/deadwood"
738
# The following upstream DNS servers are Google's
739
# (as of December 2009) public DNS servers. For
740
# more information, see the page at
741
# http://code.google.com/speed/public-dns/
743
# If neither root_servers nor upstream_servers are set,
744
# Deadwood will use the default ICANN root servers.
745
#upstream_servers = {}
746
#upstream_servers["."]="8.8.8.8, 8.8.4.4"
748
# Who is allowed to use the cache. This line
749
# allows anyone with "127.0" as the first two
750
# digits of their IP to use Deadwood
751
recursive_acl = "127.0.0.1/16"
753
# Maximum number of pending requests
756
# Send SERVER FAIL when overloaded
759
maradns_uid = 99 # UID Deadwood runs as
760
maradns_gid = 99 # GID Deadwood runs as
762
maximum_cache_elements = 60000
764
# If you want to read and write the cache from disk,
765
# make sure chroot_dir above is readable and writable
766
# by the maradns_uid/gid above, and uncomment the
768
#cache_file = "dw_cache"
770
# If your upstream DNS server converts "not there" DNS replies
771
# in to IPs, this parameter allows Deadwood to convert any reply
772
# with a given IP back in to a "not there" IP. If any of the IPs
773
# listed below are in a DNS answer, Deadwood converts the answer
774
# in to a "not there"
775
#ip_blacklist = "10.222.33.44, 10.222.3.55"
777
# By default, for security reasons, Deadwood does not allow IPs in
778
# the 192.168.x.x, 172.[16-31].x.x, 10.x.x.x, 127.x.x.x,
779
# 169.254.x.x, 224.x.x.x, or 0.0.x.x range. If using Deadwood
780
# to resolve names on an internal network, uncomment the
787
Deadwood does not follow RFC2181's advice to ignore DNS responses with the TC
788
(truncated) bit set, but instead extracts the first RR. If this is not
789
desired, set the undocumented parameter truncation_hack to 0 (but
790
read the DNS over TCP section of this man page).
793
Deadwood can not process DNS resource record types with numbers between
794
65392 and 65407. These RR types are marked by the IANA for "private use";
795
Deadwood reserves these record types for internal use. This is only 16
796
record types out of the 65536 possible DNS record types (only 71 have
797
actually been assigned by IANA, so this is a non-issue in the real world).
800
It is not clear whether the DNS RFCs allow ASCII control characters
801
in DNS names. Even if they were, Deadwood does not allow ASCII
802
control characters (bytes with a value less then 32) in DNS names.
803
Other characters (UTF-8, etc.) are allowed.
805
<h1>LEGAL DISCLAIMER</h1>
806
THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS
807
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
808
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
809
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE
810
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
811
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
812
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
813
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
814
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
815
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
816
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
819
Sam Trenholme (<A href=http://www.samiam.org/>http://www.samiam.org</a>) is
820
responsible for this program and man page. He appreciates all of
821
Jean-Jacques Sarton's help giving this program IPv6 support.
added
removed
deadwood-3.2.07/doc/Deadwood.ej
