default local DNS caching name server
william at firstyear.id.au
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 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
> > 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.
I don't use the OpenVPN dns cache.
William Brown <william at firstyear.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the devel