default local DNS caching name server

[Paul Wouters]

On Sun, 13 Apr 2014, William Brown wrote:

>> Now can we go back to actually discussion technical arguments again?
>
> Actually no.
>
> This whole thread has forgotten one major thing ... use cases.

That was in response to someone using appeal of authority statements, not
factual discussions.

> Proposal is to add a local caching DNS server to fedora systems. This
> may or may not accept a DHCP provided forwarder(?).

Yes. It depends on the "trustworthiness" of the network and or
preconfiguration of some of your own networks you join.

> Case 1: Standard home user. Has little knowledge of DNS, and a router
> provided by their ISP. DHCP provides the laptop with the DNS ip of the
> router, which then acts as a forwarder to the ISP

Works reasonably well with unbound+dnssec-triger, could use better NM
integration for captive portals.

> Case 2: Moderate home user. They have a little knowledge of DNS, and
> have setup a system like OpenWRT or gargoyle on their router. They have
> their own zone, .local . This means that their DHCP provides the DNS ip
> of the router to clients.

Same if their wifi is closed (eg WPA2), will need an exception in NM if
their wifi is open for the .local forward.

> Case 3: Power home user. They likely have their own fedora router server
> or some other system setup. They run their own bind / named instance on
> their network, with their own zone or two. They have DHCP setup, perhaps
> to use DDNS updates to named.

Same as above.

> Case 4: Small business workstation. Likely the small business, like the
> power home user, has their own name server. It may be Windows DNS from
> AD, or bind.

Same as above.

> Case 5: Medium / Large business workstation. It's nearly guaranteed that
> the business runs their own zones. They have their own extensive, well
> organised bind / named setup.

When connecting to their LAN or secure wifi, same as above for one one
forwarding zone. Multiple forwarding zones would need to be configured.
It if is an enterprise, they might need their corporate CAs as well as
their zones configuration, so a corporate rpm package would make sense.

> Case 6: Fedora server in a small business: Same as the workstation,
> likely AD or bind in the office.

Same as previous

> Case 7: Fedora server in the large business. Same as the workstation.

Same as previous

> Case 8: Road warrior to the power home, small business, or large
> business. Uses VPN, and needs access to the DNS provided by the push
> dhcp / dns options from their vpn tunnel.

Same, already works if you only need the one domain that is negotiated
via the VPN (eg the IKE XAUTH domain).

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

We are not suggesting that for LAN or secure wifi. In those cases the
forward will be added. However, you don' want those forwards for open
wifi or else I can bring up "linksys" push you a forward for your
internal.domain.com and mislead you into thinking you would be going
over your VPN.

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

The cache is never fully flushed. It is only flushed for the domain
obtained via DHCP or VPN, because those entries can change. They are not
changed for anything else. If the upstream ISP could have spoofed them,
so be it - the publisher of the domains could have used DNSSEC to
prevent that from happening.

> With a good, ISP, they
> will get consistent answers to queries, and there is no point to having
> the cache. If the ISP is unreliable, they will get records that are
> incorrect (See broken TTLs etc),

There is no such things as "broken TTLs". And there is no modern
nameserver that believes or honours TTLs for months. The unbound default
is cache-max-ttl: 86400. Nothing will be cached for more than one day
regardless of the TTL received. Again, if a publisher of a zone wants
ISPs to keep their hands of their records, they should use DNSSEC
and sign their zone.

> Case 2: The user does know a bit. But when they change name records they
> may not be able to solve why a workstation can't resolve names like
> other clients.

While we could flush the entire cache on (dis)connect, I think that's
rather drastic for this kind of odd use-case. If the user runs their own
zone and their own records, they should know about DNS and TTLs. But
even so, NM could offer an option to flush the DNS cache.

> Case 3: This user does understand DNS, and they don't need DNS cache.

That depends. You need caching for DNSSEC validation, so really, every
device needs a cache, unless you want to outsource your DNSSEC
validation over an insecure transport (LAN). That seems like a very bad
idea.

> They have bind / named setup, and they would like to rely on that
> instead.

They can. DNS caches are chained. There is no reason to say you cannot
run your own cache and have a network based cache.

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

This is becoming really contrived. Again, if you think this is a real
scenario (I don't think it is) than you could run unbound with ttl=0.
But a requirement of automagically understanding what a local zone is
and automagically understanding when a remote authoritative dns server
changes data, and not willing to enforce that with ttl=0, and using
that as argument why any solution of unbound to provide a security
feature (DNSSEC) is getting a little unrealistic. If you want your
laptop to start validating TLSA and SSHP and OPENPGPKEY records, you
need DNSSEC validation on the device. The question should be "how do you
change your network requirements to meet that goal". Yes, enforcing
security comes at a price.

Let me use your scenario based on TLS. You want to be able to change
your TLS certificates and the private CA you regenerate at any time,
without any browser on your network ever giving you a popup warning.
You know you cannot ask this - it goes against the security model. The
same applies for DNS with DNSSEC. The security demands we need to do
validation and caching and we should try to make that as flexible and
painless as possible.


> Case 4, 5, 6 and 7: DNS cache, again, isn't needed.

Again, DNSSEC validation on the device requires caching.

> The infrastructure
> is well setup, and caching is done by the business servers. DNS outages
> at the business level, mean there are other issues and they will likely
> be resolved quickly. You don't want to reboot / reset interfaces for
> each time you make a change or as the first result of an issue (Again,
> this would give fedora a bad name). DNS caching may mask a bigger
> problem.

I don't really understand this paragraph.

> Case 8: Vpns are a bit unreliable, and have relatively high(ish)
> latency. But mostly they are quite good, ie openvpn. DNS cache *might*
> help here in case of traffic loss. Again, this would be masking a
> greater issue though, and could be better solved with TCP dns queries
> rather than UDP.

The VPN cases aleady work very well in Fedora. I seamlessly connect and
disconnect from the redhat VPN. Resources that are available only via
the VPN are never blocked by wrong DNS cache I got from when the VPN was
down. VPNs are a non-issue.

> In conclusion, I don't percieve that a DNS cache in Fedora is a good
> idea, as it solves few real world problems, and may in fact create
> issues, mask issues and create a bad stigma about Fedora network
> reliability. If it is to become available to users I would like:

I believe you will need to re-think that in light of running a
validating DNSSEC resolver on your laptop or servers.

> * DNS cache is not the default. It bust be enabled on a connection (IE
> user's in case 1 can enable it if needed)
> * DNS cache should be able to be enabled from the NM Gui
> * DNS cache should be able to be flushed live from the NM Gui
> * DNS cache should be flushed on route or interface state change.
> * If two interfaces are active, the default route DNS cache setting
> takes precedence.

You cannot separate dns cache from DNSSEC. DNS caching is not a problem,
it is a feature. If you don't want your records cached, use ttl=0.

Paul