RE: about "query time" (caching) +plus

2016-09-19 Thread Darcy Kevin (FCA)
"query time" (caching) +plus how I audit if a query is resolved from my local DNS or by external DNS? cheers! Pol ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list

Re: about "query time" (caching)

2016-09-19 Thread Pol Hallen
not sure hwat you mean but likely https://kb.isc.org/article/AA-01315/0/prefetch-performance-in-BIND-9.10.html exactly what I looking for! cheers! Pol ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

Re: about "query time" (caching)

2016-09-19 Thread Reindl Harald
Am 20.09.2016 um 00:12 schrieb Pol Hallen: 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

Re: about "query time" (caching) +plus

2016-09-19 Thread Pol Hallen
how I audit if a query is resolved from my local DNS or by external DNS? cheers! 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

Re: about "query time" (caching)

2016-09-19 Thread Pol Hallen
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

RE: about "query time" (caching)

2016-09-19 Thread 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