default local DNS caching name server

William Brown william at
Sun Apr 13 06:40:04 UTC 2014

On Sat, 2014-04-12 at 17:46 -0700, Andrew Lutomirski wrote:
> On Sat, Apr 12, 2014 at 5:18 PM, William Brown <william at> wrote:
> >
> >> Now can we go back to actually discussion technical arguments again?
> >
> > Actually no.
> >
> > This whole thread has forgotten one major thing ... use cases.
> >
> > Proposal is to add a local caching DNS server to fedora systems. This
> > may or may not accept a DHCP provided forwarder(?).
> >
> [snipped lots of entirely legitimate use cases]
> >
> > Now, in all of these cases the system local DNS cache *must* forward to
> > the local DNS server. You can't at the OS distinguish between any of
> > these cases with just the DHCP record or lease. It is unreasonable to
> > ask everyone to manually setup DNS on every network they join. You must
> > have the forwarder set to the DNS provided by DHCP so that you can
> > access the local network resources. You cannot suggest bypassing these.
> >
> I don't think anyone is suggesting bypassing these.  That is, all of
> your use cases *will still work*, possibly better than they do now,
> with a systemwide resolver.

A system wide resolver I am not opposed to. I am against a system wide
*caching* resolver. 

> >
> > Case 1: The user doesn't know much about DNS. the ISP might be reliable
> > or unreliable. If we assume as discussed that the cache is flushed on
> > network change, they will have an empty cache. With a good, ISP, they
> > will get consistent answers to queries, and there is no point to having
> > the cache.
> There are two good reasons for the cache:
> 1. DNSSEC.  Trusting the AD bit from the ISP is wrong.
> 2. Caching.  It's a lot better to have a correct systemwide cache than
> a bunch of per-application crappy caches.

In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a
cache is a severe detriment. 

> >
> > Case 3: This user does understand DNS, and they don't need DNS cache.
> > They have bind / named setup, and they would like to rely on that
> > instead. When they change records in their local zones, they don't want
> > to have to flush caches etc. If their ISP is unreliable, or their own
> > DNS is unreliable, a DNS cache will potentially mask this issue delaying
> > them from noticing / solving the problem.
> That's what an extremely short TTL is for.  Also, anyone relying on
> local clients not caching when TTL is already terminally screwed.
> Consider that Firefox, Chromium, Windows, and I suspect Mac OS and
> Android have caches.  The fact that Linux command line tools have no
> cache right now is not a feature.

I disable the DNS cache in firefox with developer tools. 

Additionally, a short TTL is good, for this situation, but it can't fix

Short ttls really rely on every layer of the stack actually not messing
with this. However that's another issue. 

> >
> > Case 8: Vpns are a bit unreliable, and have relatively high(ish)
> > latency. But mostly they are quite good, ie openvpn.
> Hah.  Openvpn screws up its own internal DNS cache on a regular basis
> for me.  This is a common cause of Ctrl-C.
> --Andy

I don't use the OpenVPN dns cache. 

William Brown <william at>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the devel mailing list