Deadwood beta on debian lenny

[Sam Trenholme]

> someone out there already tried to get deadwood running on debian?
> On my 64-bit lenny, it is listening, but not responding to any request.

Well, I don’t use Debian (I use CentOS 5), but I did run a huge
battery of regression tests, both in a 32-bit VMware virtual machine
and in a native 64-bit CentOS 5 environment.  The tests right now by
and large only test upstream_servers, but there is one test for
root_servers.

Anyway, here is the setup that works for me.  In one window:

$ → cat /etc/dwood3rc
bind_address="127.0.0.1"
recursive_acl="127.0.0.1/8"
chroot_dir="/etc/deadwood"
$ → ls -a /etc/deadwood/
.  ..
$ → ls -ld /etc/deadwood/
drwxr-xr-x 2 root root 4096 Jun 29 00:26 /etc/deadwood/
$ →  sudo ./Deadwood
Deadwood version 2.9.01
Deadwood: A DNS UDP non-recursive cache (IPv4-only)
We bound to 1 addresses
Using default ICANN root servers:
198.41.0.4,192.228.79.201,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.241,192.112.36.4,128.63.2.53,192.36.148.17,192.58.128.30,193.0.14.129,199.7.83.42,202.12.27.33
reset_rem DwRecurse 1941 0
reset_rem DwRecurse 1941 2
reset_rem DwRecurse 1941 1
reset_rem DwRecurse 1941 3
reset_rem DwRecurse 1941 4

And in another window, let’s try resolving some names:

>> A simple hostname to resolve; indeed the first hostname I got to
recursively resolve a couple of months ago <<
$ → askmara Awww.google.com.
# Querying the server with the IP 127.0.0.1
# Question: Awww.google.com.
www.google.com. +300 cname www.l.google.com.
#www.l.google.com. +300 a 66.102.7.104
#www.l.google.com. +300 a 66.102.7.99
# NS replies:
# AR replies:

>> A slightly more complicated hostname to resolve that requires glueless NS support to resolve <<
$ → askmara Asamiam.org.
# Querying the server with the IP 127.0.0.1
# Question: Asamiam.org.
samiam.org. +86400 a 209.172.32.214
# NS replies:
# AR replies:

>> This one is very tough to resolve.  Not only are there a number of complicated CNAME paths to follow, not to mention glueless NS chains to chase down and solve, but two of the three kintera.org nameservers are down <<
$ → askmara Awww.gbod.org.
# Querying the server with the IP 127.0.0.1
# Remote server said: SERVER FAILURE
# Question: Awww.gbod.org.
# NS replies:
# AR replies:

>> OK, we didn't succeed the first time.  However, we finally get this domain to resolve the second time we try.  This particular domain name didn't resolve with Deadwood until yesterday <<
$ → askmara Awww.gbod.org.
# Querying the server with the IP 127.0.0.1
# Question: Awww.gbod.org.
www.gbod.org. +3600 cname unitedmethodist.kintera.org.
#unitedmethodist.kintera.org. +3600 cname kinteracust.kintera.org.
#kinteracust.kintera.org. +3600 cname www.kintera.org.edgekey.net.
#www.kintera.org.edgekey.net. +3600 cname e1291.b.akamaiedge.net.
#e1291.b.akamaiedge.net. +3600 a 96.17.213.103
# NS replies:
# AR replies:

So, that in mind:

* Use the above /etc/dwood3rc

* Make sure there is an empty directory called /etc/deadwood/ owned by root

* Don’t try daemonizing Deadwood; just run it from the command line
(I’m in the deadwood-2.9.01/src directory above and ran a “make -f
Makefile.centos5” to compile Deadwood before the “sudo ./Deadwood”)

* See if things work by using dig or askmara to resolve various common
domains, or by having an /etc/resolv.conf with the line “nameserver
192.168.189.2” in it

Keep in mind this is a beta-test release. Please post any bug reports
of domains not resolving at all, domains resolving differently than
they do in BIND/dnscache/PowerDNS recursor/Unbound/whatever, Valgrind
memory leak reports, crashes (with stack traces or repeatable recipes
to reproduce please), or what not here on the mailing list.

The program is feature-complete, so I am not interested in feature
requests, only in bug reports.  Feature requests will be responded to
by requests for money and/or patches.  For an explanation for why I
work like this, read this blog from former Samba developer Gerry
Carter:

http://www.plainjoe.org/blog/?p=11

“There is a time in the development cycle to fix bugs, and there is a
time to focus on pushing features forward [...] as a general rule the
bug fix phase and the feature work phase should be partitioned into
separate cycles.”

- Sam

Note: I do not answer MaraDNS (including Deadwood) support requests
sent by private email without being compensated for my time. A MaraDNS
support request is any and all discussion you may wish to have about
MaraDNS in private email; if you want to email me to talk about
MaraDNS then, yes, that is a support request. I will discuss rates if
you want this kind of support. Thank you for your understanding.

MaraDNS security vulnerability reports, however, will be dealt with
without charge and kept confidential. If you don't know what Bugtraq
is, then, no, your email is not a security report. It is not a
security report unless you've done due diligence to determine how the
security bug you think you found can reasonably be exploited.