Re: Working with a local DNS cache

[Dan Williams <dcbw redhat com>]

On Wed, 2009-08-05 at 20:27 -0700, Adam Langley wrote:
> Hi,
> 
> I'm one of the developers on Chromium[1] (aka Google Chrome) for
> Linux. Chromium likes to prefetch DNS records a lot and, as such, we
> would very much like it if Linux systems came with a local DNS cache.
> 
> To that end, I'm hacking up DJB's public domain DNS cache[2] to build
> with autotools, have a DBus interface etc[3], in the hope that it can
> turn into a painless package install and, in time, become standard
> practice.

These days I'd rather just use a local caching nameserver by default in
NM, and let those that don't want it turn it off or something.

The most common local caching nameserver is currently dnsmasq, and it
also provides a D-Bus interface.  If at all possible, we should try to
use *one* dbus interface.  Not sure if you've looked at the dnsmasq dbus
API, but it might be worth a glance.

That said, if we really can't agree on a common D-Bus interface, we can
certainly wrap stuff in NetworkManager.  There's a few considerations
however:

1) if each daemon implements a different dbus interface, how do we
determine what daemon NM sends zones to?  All of them?  Priority list?
Command-line switch (ugh) ?

2) We need to do "split DNS", ie for all zones "*.foo.com" query this
set of nameservers, but for all other zones, query a different set.
This was originally what we wanted to use a local caching nameserver for
in NM.

> An important part of this would be to have NetworkManager configure
> the DNS cache when it gets new resolver information. I did a 10 minute
> hack[4] and it would be great if someone could let me know if I'm
> heading in the wrong direction at this stage. The part which mostly
> gives me pause for thought is that I'm making a DBus RPC call in
> named-manager, and I don't know if that's verboten because of latency
> considerations.

Yeah, that's more or less what gets done.  The less-hacking approach
would be:

1) Make SetServersForDomain() actually take a domain so we can do split
DNS.  That's actually a deal-breaker (see above)...  Obviously the
default domain would be something like "" (zero-length string) or "*".

2) Should be making an async D-Bus call here so that NM doesn't block.
This would take a bit of re-architecting inside NM but it's not
impossible; IP config information is updated in a few places but it
looks like a bit of work could make it happen async.

3) Potentially multiple caching nameserver implementations; dnsmasq has
been around for ages and has provided a dbus interface for a few years,
we just never got around to making NM talk to it.  bind had a dbus
interface a long time back, but people really objected to running bind
on a desktop for some reason, so we dropped that.  In any case, whatever
we pick has to be able to handle different D-Bus APIs, probably through
use of a GInterface to abstract them to the namedmanager, and then small
implementations for each caching nameserver implementation that
implement the GInterface.

All in all, not too hard, and definitely something that's been wanted
for a while!

Dan