answers from cache- verification

[Barry Margolin]

In article <g3cqqf$68m$1 at sf1.isc.org>, Kevin Darcy <kcd at chrysler.com> 
wrote:

> 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
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***