On Sat, Apr 12, 2014 at 12:38:41PM +0930, William Brown wrote:
I agree with the goal to add DNSSEC (Despite it's flaws). However, a caching DNS server can create many headaches without a number of considerations.
First, it should be easily possible to clear / invalidate the cache for a GUI and CLI user. This isn't possible on windows for example, and is why often they ask people to reboot computers in the first instance of an issue or migration. Additionally, every time the interface state changes from up/down, or the default route changes, the cache should be cleared. Consider a user of a corporate network that serves both an internal zone and an external zone. The user may enter or exit the network, and cached records would continue to be served causing issue.
Second, it can create issues as otherwise mentioned by "dodgy" hotspots. They server a fake DNS record for all hosts that resolves to the hostspot. When the client authenticates they begin to serve the real records. If these records are cached, suddenly, the hotspot is now unusable (Especially if they don't set a TTL of say 1.) This would create frustration with users who didn't realise they needed to flush their cache (See 1 ...)
Finally, I don't think it should be the default in the server product of fedora. We often have a bind server on networks for servers which is caching already.
I agree on all points above except this one. Servers ESPECIALLY need to have a local DNS cache so they can continue working correctly when the primary nameserver goes down. In fact, the server case is even simpler--it can simply forward all requests to the first corporate/datacenter nameserver until it fails, and then fail over to the 2nd or 3rd DNS server in that case. It may not even have to support full DNSSEC validation because you may trust the datacenter's nameserver to do that for you. It certainly wouldn't have to deal with all the corner cases that clients have to deal with that you mention above such as flushing the cache on network link or route changes, VPN connection/disconnection, captive portals, etc.
In fact, this is such an important use case that I'm tempted to create a separate Fedora Change for the Server Product with just this very basic limited functionality because we can do this very simply today without getting bogged down in the quagmire of DNSSEC, NTP bootstrapping, and all the client issues above.