> 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.
Not really: Every network you join, you have to semi-trust. If you don't
trust it, why did you join it?
There are too many cases where the network admin is correct, and does
the right thing. It's more the exception I think that the network is
> 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.
But you can't account for every captive portal in the world. This is why
the cache is a bad idea, because you can't possibly account for every
system that is captive like this.
> 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.
What if I call my network .concrete. Or .starfish. Or any other weird
thing I have seen on personal networks. Again, you cannot bypass the
local network DNS as the forwarder. You must respect it.
> 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.
How do you plan to make this work? You can't magically discover all the
DNS zones hosted in an enterprise. At my work we run nearly 100 zones,
and they are all based at different points (IE, a.com, b.com, c.com.)
You cannot assume a business has just "a.com" and you can forward all
quieries for subtree.a.com
to that network server.
Again, you *must* respect the DHCP provided DNS server as the forwarder
else you will savagely break things.
> 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).
You can negotiate more than one domain on a VPN .... again, see above.
> 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
and mislead you into thinking you would be going
over your VPN.
This is a more serious problem, than a caching resolver could hope to
solve as it shows malicious intent.
> 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.
No no no!!!! You need to flush *all* entries. Consider what I resolve
to. That changes *per* ISP because google provides
different DNS endpoints and zones to ISPs to optimise traffic! So when I
use google at work, I'm now getting a suboptimal route to their servers!
> 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.
So that's a valid point: A non-caching unbound that caps TTLs is a good
idea, but as you say, you can't stop a dodgy ISP.
> 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.
But this isn't even an odd use case. There are enough power users in the
world who do this. It's not just computer enthusiasts, I know a chemist
who did this, and others. You can't just assume a generic case, and then
break it for others.
> 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
If your lan is insecure, you have other issues. That isn't the problem
you are trying to solve.
> They have bind / named setup, and they would like to rely on that
They can. DNS caches are chained. There is no reason to say you cannot
run your own cache and have a network based cache.
But you don't *need* it. I went to efforts to setup my own bind to
cache, I shouldn't need it on my system. Again, local caches cause all
kinds of issues. A home user is likely to toy with things and set a
high-ish ttl, say even 10 minutes, and change records on their server.
Then their records appear broken, because the local cache isn't expired
> 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.
It's not contrived: This is a common network setup for all the people I
know who are enthusiasts or how they setup their home networks. This is
why it's a use case.
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.
The issue is that by adding DNSSEC in this way, you are going to cause a
great deal of pain because these caches. Add DNSSEC, but if you need to
cache, cache for the most minimal time 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
I don't really understand this paragraph.
It's linked to the other cases. It's the point that local system caches
aren't needed as you have access to highly reliable DNS systems.
Additionally, business networks are "trusted" so you can trust their DNS
caches etc. (to a point)
> 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.
Consider a business with external and internal DNS zones. This becomes
an issue in this case. If you have cached say "website.example.com" to
the external IP, and that is DMZed somehow on the internal network, when
you change to VPN, you need to use the internal view of that zone
instead. But you can't the name is cached.
> 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.
No, cache is not a feature. It's a chronic issue. Look at windows
systems that service desks around the world always advise the first step
is reboot: Why? Flush dns caches (Or other things). When you can't get
to a website? Restart the webbrower, to flush the cache. Intermittent
network issues for different people on a network? The cache is allowing
some people to work, but masking the issue to them. It's not allowing
people to quickly and effectively isolate issues.
DNSSEC is a good idea: Caches are a problem.
If this really is to be used, I cannot stress enough, that a cache must
be completely flushed every time the default route or network interface
changes. You can't, and I can't possibly conceive every network setup in
the world. If you make assumptions like this, systems will break and
fedora will be blamed.
William Brown <william(a)firstyear.id.au>