[MaraDNS list] How to get MaraDNS and Deadwood to talk to each other?

[Sam Trenholme]

> My ISP is Comcast, and despite the poor quality of their customer service,
> they are the only residential-grade ISP working really hard towards full
> IPv6 deployment.

Well, since I'm using Comcast right now, I will hopefully have IPv6
sooner rather than later.  I might even have Deadwood's and MaraDNS'
IPv6 functionality fully tested by the end of the year.

> This
> brought me to look at MaraDNS because of the use of text files for storage,
> but I might also give BIND another shot, too.

NSD uses text files converted in to binary data for storage but has no
recursion (use Unbound).  BIND is the only currently maintained DNS
server with both recursion and authoritative DNS in the same daemon.

The thinking with Unbound/NSD and Deadwood/MaraDNS is that you have
one daemon which supplies answers to DNS questions, and another daemon
which looks for answers to DNS questions.  They are rather distinct
roles best served by distinct daemons.

> That all said, and possibly due to some of my inexperience in advanced C
> projects and not a deep understanding of DNS, wouldn't looking through the
> results of a DNS response for any A records before AAAA be just a basic,
> repeated string search?  I would imagine that shouldn't be *too* ugly a
> piece of code.  What about looking for AAAA before A?  I have noticed that a
> lot of dual-stack network implementations do this by querying first for
> AAAA, then trying again for A when they get NXDOMAIN or another such error.

I see you haven't become acquainted with the monstrosity that is DNS.

When you get a NS referral, the referral is by name, not by IP.  A DNS
response referring you to another DNS server doesn't say "the DNS
server for whatever.foo is 10.1.2.3".  No, it tells you something like
"the DNS server for whatever.foo has the name dns.isp.foo".  If you're
lucky, you will also get a "glue" record: "the IP for dns.isp.foo is
10.1.2.3" and maybe even "The IP6 for dns.isp.foo is
fd4d:6172:6144:4e53::10:123".

Glues NS referrals are pretty easy to deal with and Deadwood should
handle that case with both IP4 and IP6 just fine (IP6 hasn't been
tested, mind you).

Now, in an IPv4 only network, if we get a glueless NS referral, we
then simply look for the IP4 IP for that record, find it, and then
solve the query.

In a mixed IP4 and IP6 network, DNS gives us no information whether
the glueless NS referral is found on an IP4 network, an IP6 network,
or both.  So, we would have to do the following:

* Look for the IP4 for the glueless NS referral.

* If we're given a "not there" or NX reply, look for the IP6 for the
glueless NS referral.

* Once we get this IP6 address, ask for information from that DNS
server and continue our search.

It can be done, but the code to do it will be rather ugly, especially
since Deadwood uses the "select() model" instead of threads to do all
of this processing.  It will probably take a couple of months to pull
off.

I'm not going to touch this until I am on an IPv6 network at home.

There's also the issue with adding IPv6 to the Windows Deadwood service.

- Sam