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