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:[email protected]] On Behalf Of Pol
Hallen
Sent: Monday, September 19, 2016 5:43 PM
To: [email protected]
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
[email protected]
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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
