[Dnsmasq-discuss] Feature Proposal: DNS Recursor

[Simon Kelley]

Loune Lam wrote:
> Hi All,
> 
> I've been using dnsmasq for a long time and it has been working 
> brilliantly. One feature I find that it's missing though, is a DNS 
> recursor. Having the ability to recurse would make it the most 
> lightweight self-containing DNS server/Cache. I've done some preliminary 
> investigations on how this could be done, which I've outlined below. If 
> Simon and others here are interested I'd be happy to create a patch for 
> inclusion in the mainline.

I'd certainly consider this, but I'm not sure it's a good idea.

It's a lot of extra code, when dnsmasq tries to be small.

Most  dnsmasq installations don't need it, indeed dnsmasq allows people
to have their own nameserver without having their own _recursive_
nameserver. I'm not sure it's a good idea to encourage every leaf node
on the net to run  a recursive server. When your ISP's nameserver looks
up www.google.com at Google's authoritative server, it shares that
information with thousands of customers. If all those customers run
recursive servers, they all have to talk to Google's servers.

Doing recursive DNS without generating security holes seems to be hard.
I certainly don't know enough to be sure of doing it safely without a
lot of research. Solutions are already available which have tackled the
problems. (see below)

Those people who have needed this, have generally done it by using
dnsmasq as a front end and pointing it at dnscache or something similar.
That seems to work pretty well.

If you want to patch dnsmasq for your own use, and make the changes
available, that's great. Use the power of Free Software. If the patch
allows conditional compilation of the recursor, and looks like it won't
be a big ongoing maintenance headache, I _might_ take it into the
mainline, but no promises. A chorus of "but we'd love that feature" on
here would help sway me.

> 
> 
> *** Possible Recursor Implementation for DNSMasq
> 
> -frec will have 4 new fields - nameservers, recurse_depth, lookup 
> callback & closure
> 
> -There will be 3 new functions recurse() resolve() recursor_resolved() 
> inside forward.c (or recurse.c?)
> 
> -In process_reply() if lookup results in 'refused to do a recursive 
> query', then recurse() is called with HEADER and frec.
> 
> -recurse() take the NSes obtained from HEADER and if available the 
> additional RR (glue) IPs are populated into frec.nameservers and 
> forward_query() run with same frec and rebuilt question HEADER (ie. 
> retry with next namewserver). If there are no glue records, then 
> additional resolution of nameserver IP is neccessary. resolve() is 
> called providing recursor_resolved() as a callback and frec as closure 
> (new branch of resolution).
> 
> -everytime recurse() is called frec.recurse_depth is increased. if 
> recurse_depth > 10, then automatic failure
> 
> -resolve() will take recurse_depth, callback, closure and question 
> HEADER, lookup the cache (answer_request()) and if found call the 
> callback before returning. If not, forward_query() will be called with 
> generated header and new frec (setting frec.recurse_depth, frec.callback 
> and frec.closure).
> 
> -Any place which triggers send_from will need to be amended to: if 
> callback is not NULL to run the callback with HEADER & closure, 
> otherwise send_from as usual
> 
> -callback recursor_resolved() will be called when resolution finishes. 
> It will accept HEADER and the closure frec as parameters. It will 
> populate the NS answer IPs from HEADER into closure frec and trigger 
> forward_query() run with closure frec and rebuilt question HEADER.
> 
> -forward_query() will, if available, look up using nameservers stored in 
> frec
> 
> 
> *** Questions
> 
> -How to best store nameservers in frec?
> 
> -How are stale frecs handled? ie. If nameservers don't respond?
> 
They're garbage-collected in get_new_frec

> -Should Additional RRs be cached as well? (poisoning implications)
> 
> -Seems like that DNSMasq doesn't resolve CNAMEs - mechanism to 
> recursively resolve CNAMEs will need to be built. The answer HEADER will 
> need to be modified to include the CNAME and the A record in the answer.

It does, there's code to store and resolve CNAMEs in the cache module.


Cheers,

Simon.