Delivery of non-cached replies

[Sam Trenholme]

> I currently try to include Deadwood as caching DNS server in the CernVM
> appliance.  So Deadwood will in certain setups talk to the DNS servers
> of a virtual machine monitor's NAT layer.

First of all, I'm very happy to see my software being used by
significant organizations such as the one that invented the world wide
web (and, on the side, does some really cool physics that would
impress even Sheldon from the American sitcom /The Big Bang Theory/).
:)

> I had a particular problem with VMware Fusion and negative replies.

What happens exactly when you have the problem?  I need to know what
kind of issue your patch fixes so I can properly document it.

I know that VMware messes around with DNS packets. In particular, I
have been unable to use my virtual machine running VMware player to
make DNS packets visible to the host (this is one reason Deadwood has
full Windows support).  Also, DNS packets received by the VMware
player guess have their TTLs changed to always be five seconds.

Deadwood does cache negative replies.  An empty packet is a packet
without any answers (in particular, a DNS packet without any data in
the AN, NS, nor AR section of the reply).  A DNS negative reply is one
with an answer in the NS section of the reply.  The thinking behind
not sending packets without AN/NS/AR replies is that they might
confuse stub resolvers; in my case these packets would cause my
browser to have "we can not reach this website" error messages.

> Deadwood is not able to cache such answers with the error "Empty packet"
> and then drops the reply.  I uploaded a small tcpdump file where I
> queried for an non-existing domain:
> https://jblomer.web.cern.ch/jblomer/dns-nxdomain.dump.

I just looked at this file.  It's a strange binary file (and isn't a
raw DNS packet; I know what those look like) which I will need to
install a special program to look at.  Do you have handy tools that
convert this to ASCII, so that you can post it to the list and we can
look at it and discuss it on the list?

> While I didn't look into the particular problem, as a workaround it
> would be helpful to deliver a DNS response, even if it could not be
> added to the cache.  Since this way all sorts of crap is possibly
> delivered, perhaps this behaviour can be added optionally (see patch below).

I really appreciate this kind of bug report and contribution being
made to MaraDNS' codebase.  The reason why I check for "blank" replies
is because I was having some real-world problems last summer where
invalid DNS replies were being cached, making websites inaccessible
until the bad entries were removed from the cache.

Does this patch fix the problem for you?  If you confirm that it does,
I will document the new feature (RTFM isn't very helpful if the
documentation is incomplete), apply your patch to the stable (2.3)
branch of Deadwood, forward-port it to the development (2.4) branch of
Deadwood, and should have time this afternoon to release new snapshots
of the program.

One note about the patch: When a new DwMararc variable is added, it's
my coding style to have its inital value set in the function
dwm_init_mararc() in the file DwMararc.c; this way we guarantee the
parameter always has a default value.  In addition, my documentation
style is to always have the default value pointed out in the
documentation.  I haven't documented this particular bit of Deadwood
coding style, but I really should do this.

- Sam

Note: I do not answer MaraDNS support requests sent by private email
without being compensated for my time. I will discuss rates if you
want this kind of support. Thank you for your understanding.