Now can we go back to actually discussion technical arguments again?
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(?).
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
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.
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.
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.
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.
Case 6: Fedora server in a small business: Same as the workstation,
likely AD or bind in the office.
Case 7: Fedora server in the large business. Same as the workstation.
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.
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.
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. If the ISP is unreliable, they will get records that are
incorrect (See broken TTLs etc), or no record at all. The cache will
only help once a record has been returned once, and will only aleviate
pain "later" in the session. So DNS caching *may* help here.
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. We don't want to give Fedora the same name as Windows,
where you need to turn on/off the network interface all the time to
solve issues (to flush the DNS cache). In this example, the user wants
their router to (maybe) cache the records, and to absolve this from
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.
Case 4, 5, 6 and 7: DNS cache, again, isn't needed. 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
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.
Only case 1 and 8 have real reasons to use a local OS dns cache.
However, you can not distinguish these from the other cases at a network
level. IE you couldn't make the cache easily enabled / disabled based on
some network parameter.
Additionally, case 1 is only needed in the situation that you have a low
quality connection, or a low quality ISP forwarder. Both of these are
issues you should take up with your ISP, and shouldn't be solved by
Case 8 with the VPN, is inherently hard to fix. VPN reliability is
always improving and I think it's becoming less of an issue. I would
also say it's a "rarer" use case than the others.
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:
* 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
William Brown <william(a)firstyear.id.au>