about "query time" (caching)

[Darcy Kevin (FCA)]

In the first case, your resolver probably had to resolve all levels of the hierarchy from the root all of the way down to the leaf node (root, .it, yahoo.it and then the leaf records). 96 msec.

In the second case, the answer was cached and so your resolver didn't have to talk to anything on the Internet at all. 1 msec.

In the third case, the A records had expired from the cache (since the TTL on those records is 300 seconds = 5 minutes), so your resolver needed to fetch a fresh set from the yahoo.it nameservers -- the NS records of which were most likely cached from the first lookup -- but it didn't need to follow the referral chain all of the way down from the root. 19 msec.

This all seems reasonable and expected, to me.

										- Kevin
-----Original Message-----
From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Pol Hallen
Sent: Monday, September 19, 2016 5:43 PM
To: bind-users at lists.isc.org
Subject: about "query time" (caching)

Hi all,

I'm struggling about "query time" :-/
Using bind 9.9.5, I configurated it as caching proxy:

dig yahoo.it @192.168.1.212
[...]
96msec

second time:

dig yahoo.it @192.168.1.212
[...]
1msec

seems it works but: if I waiting (ie 5 minutes) and I re-run same command, "query time" was increased:

19msec

why? If the record "yahoo.it" is inside cache why after 5 minutes "query time" is 19msec?

thanks all for help!

Pol
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users