default local DNS caching name server

Chuck Anderson cra at WPI.EDU
Sat Apr 12 13:49:22 UTC 2014


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.


More information about the devel mailing list