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.