default local DNS caching name server

[William Brown]

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 firstyear.id.au> 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
everything. 

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 firstyear.id.au>
-------------- 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: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140413/281071e5/attachment.sig>