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-boun...@lists.isc.org] On Behalf Of Pol Hallen Sent: Monday, September 19, 2016 5:43 PM To: bind-users@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users