Odd behavior with caching-only DNS servers
Mark_Andrews at isc.org
Thu Feb 9 21:22:21 UTC 2006
> 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
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
> 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 Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users