answers from cache- verification
barmar at alum.mit.edu
Thu Jun 19 05:34:38 UTC 2008
In article <g3cqqf$68m$1 at sf1.isc.org>, Kevin Darcy <kcd at chrysler.com>
> Alan Clegg wrote:
> > Louis Luciano wrote:
> >> Do you know the cleanest way to verify that repeated DNS requests to a
> >> caching-only DNS 9.3.2 nameserver are truly being satisfied from cache?
> > Watch for a decreasing TTL.
> Well, _theoretically_ the TTL of the RRset on the master could be
> changing over time, so declining TTL values is technically only a
> _heuristic_ method of verifying that the answers are coming from cache.
> I suppose one could intersperse SOA queries in between the probe queries
> in order to confirm that the zone did not change, but how rigorous do we
> want to be here?
Well, if you're worried about theoretical possibilities, it's also
possible that they don't update the SOA serial number when they change
the TTLs. If they're not using zone transfer to replicate to slave
servers there's no need to increment the serial number.
> The better way, surely, is to see if there is any
> "backend" query traffic between the putative caching resolver and the
> authoritative server(s) for the zone.
> On 9.4.x or higher, of course, another option presents itself: restrict
> cache access via allow-query-cache, and thereby see if the queries fail.
These require access to the server or its local network. I wonder if
the OP is trying to do this from the client or is server-side
verification OK? In the latter case you could simply turn on debug
logging and see whether it performs a recursive query.
Barry Margolin, barmar at alum.mit.edu
*** PLEASE don't copy me on replies, I'll read them in the group ***
More information about the bind-users