Odd behavior with caching-only DNS servers

[Mark Andrews]

> At my company, we have our DMZ hosts setup to use 3 caching-only DNS
> servers dedicated to the DMZ environment.  The servers are running BIND
> 9.3.2 on Solaris 9.  The issue that I'm seeing / that is perplexing me
> thus far is this.  If I add a host on our primary DNS server (via the
> QIP IP Management interface), I can resolve the host by name or IP
> immediately from these caching only servers.

	Because there is no cached information about these hosts
	*before* the addition.  If there had been queries for the
	records there would be negative cache information and that
	would have to time out the same as positive cache information.

>  However, when a host is
> deleted and/or updated on the primary, the odd behavior begins.  Namely,
> while a lookup on any of our authoritative results fails (as expected),
> I am still able to lookup the host info (by name or IP) on these
> caching-only servers.

	That's how caches work.  They remember the information until
	the TTL expires.

> The only way I've been able to get this outdated
> info purged is by stopping / restarting the name server, flushing the
> cache, or simply waiting for the TTL to expire (per the default TTL
> setting in place).  Aside from this issue, another involves involves a
> host who originally had one IP but was moved to another.  A lookup by IP
> on some of these caching-only servers returns the expected result but a
> hostname lookup returns the old IP address.  This issue is more
> prevalent on one of the 3 servers than the other 2 but an issue
> nonetheless.

	You have different query patterns on the servers.

> What's further frustrating is that our internal servers are configured
> to forward queries outside our domain to a set of 3 caching-only servers
> (separate from the DMZ servers), where the queries in the aforementioned
> scenarios work as expected (i.e. query failing or returning updated
> info).  
> 
> In terms of the BIND configuration, they are more or less identical sans
> ACL's restricting who can/can't query them.  I've been working this
> issue for a bit now but nothing obvious is sticking out at me.  I can
> easily resolve things by making the default TTL lower but that is really
> not the answer.
> 
> Any insight, suggestions, etc would be appreciated.
> 
> - Bill

	If you know you are going to change a RRset lower the TTL
	on that RRset atleast a TTL period before the intended
	change to the data in the RRset.  Restore the TTL when you
	change the data.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org