Deadwood beta on debian lenny

[Sam Trenholme]

> However, I’m thinking it may be better to verify that we always store
> “not there” replies in the same location as the original query (I’m
> pretty sure Deadwood already does this, but I have to look at the code
> again to make sure) and to not perform a bailiwick check for “not
> there” replies at all.

OK, I’ve done this.

I have verified that “not there” replies are always stored in the
cache with the same name as the original DNS query.  Here is the
relevant code around line 2051 of DwRecurse.c:

        if(type == TYPE_ANSWER || type == TYPE_NXDOMAIN ||
                        type == TYPE_NOT_THERE) {
                dw_log_dwstr("Caching direct answer at ",query,100);
                dwh_add(cache,query,action,ttl,1);
                ret = 1;
                goto catch_dwx_cache_reply;
        }

The “type” is the type of answer we get; a NXDOMAIN is different from
a “NOT THERE” because a NXDOMAIN tells us there is no record of any
type for the query we ask; a “NOT THERE” tells us there are other
records with the same name.  TYPE_ANSWER is a direct answer to our
question (such as the IP for “maria-jose.kabah.foo”)

The “dwh_add()” call adds the answer to the cache; “cache” is the DNS
cache; “query” is the original DNS question; “action” is the data we
put in the cache; “ttl” is the TTL for the record (shortest TTL when
we see a CNAME chain); and “1” is used to indicate that this record
will be removed from the cache when the cache is full and we need to
flush records not recently accessed.

This code only will cache a query in the location the original query
was made; it completely stops AR-injection cache poisoning attacks.

I have also updated the caching code to not perform bailiwick checks
for answers which are not NS referrals (since NS referrals are the
only records where we have to be real careful with bailiwick; the
location to cache a NS referral depends on how much of the DNS tree
the NS referral covers, and we have to make sure a given referral
doesn’t control more of the DNS tree than it should be able to
control); this will slightly speed up processing of non-NS referrals
and resolves the issues Sebastian reported a couple of days ago.

The updated patch:

http://maradns.org/deadwood/patches/deadwood-2.9.01-show_not_there_2.patch

And the updated tarball:

http://maradns.org/deadwood/snap/deadwood-H-20100728-2.tar.bz2

With GPG sig:

http://maradns.org/deadwood/snap/deadwood-H-20100728-2.tar.bz2.asc

- 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.