default local DNS caching name server

[Andrew Lutomirski]

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.

>
> 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.

>
> 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.

>
> 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