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

You could turn on debugging, to be sure. Or, you could just dump your cache and see what's in it or not, expired or not. Anything lacking a valid, unexpired cache entry is going to require communication with the outside to resolve, which is going to introduce some measure of delay.

Re: about "query time" (caching)

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)

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

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)

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)

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

Re: lookout timesouts

In message

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

Re: replicate a whole master

On Mon, Sep 19, 2016 at 04:40:17PM +0100, Tony Finch wrote: > /dev/rob0 wrote: > > > > If you're thinking that you can do this replication to improve DNS > > performance, you're right, it will do that. But it certainly will > > not scale (if it's even possible to get axfr/ixfr),

RPZ on forwarder not working when forwarder is slave

I'm attempting to set up a response policy zone on a pair of forwarders running BIND, version 9.8.1 on the master for the zone, and version 9.9.5 on the slave. The forwarding requests are coming from a pair of Microsoft DNS servers, running Server 2012. If the Microsoft DNS server is configured

Re: replicate a whole master

> On Sep 19, 2016, at 8:40 AM, Tony Finch wrote: > > /dev/rob0 wrote: >> >> If you're thinking that you can do this replication to improve DNS >> performance, you're right, it will do that. But it certainly will >> not scale (if it's even possible to get

Re: replicate a whole master

/dev/rob0 wrote: > > If you're thinking that you can do this replication to improve DNS > performance, you're right, it will do that. But it certainly will > not scale (if it's even possible to get axfr/ixfr), and it won't > handle modern CDN systems properly. BIND 9.10 and

Re: replicate a whole master

On Mon, Sep 19, 2016 at 03:51:17PM +0200, Pol Hallen wrote: > dig yahoo.it @192.168.1.212 > > query is 38ms, second query is 1msec > > Can I replicate a whole internet primary dns to have on my bind in > local network all domains name updated? "Internet primary dns", are you referring to the

Re: replicate a whole master

Huh? are you sure you want to replicate whole server? Are you sure you know what that means? mhmh... now I'm not sure :-' what does entail this? thanks Pol ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from

Re: replicate a whole master

On 19.09.16 15:51, Pol Hallen wrote: dig yahoo.it @192.168.1.212 query is 38ms, second query is 1msec Can I replicate a whole internet primary dns to have on my bind in local network all domains name updated? are you sure you want to replicate whole server? Are you sure you know what that

Re: lookout timesouts

Hi there, On Mon, 19 Sep 2016, bind-users-requ...@lists.isc.org wrote: We have a customer who has their own cache server, but in the afternoons before they close up for the day, they commit off-site backups, this process takes them about 90 mins, anyone trying to use the internet in this time

replicate a whole master

Hi all :-) dig yahoo.it @192.168.1.212 query is 38ms, second query is 1msec Can I replicate a whole internet primary dns to have on my bind in local network all domains name updated? Is 38ms an acceptable results? thanks for help Pol dig yahoo.it @192.168.1.212 ; <<>> DiG

Re: BIND-RPZ and Views

Tom wrote: > > What is the supported/preferred way for implementing slave-rpz's in views? > I want to achieve, that view1 has a different policy-configuration (passthru, > given, nxdomain..) than the ones configured in view2 using the same > slave-rpz-files. If not

lookout timesouts

Hi, We have a customer who has their own cache server, but in the afternoons before they close up for the day, they commit off-site backups, this process takes them about 90 mins, anyone trying to use the internet in this time fails 99.9% of the time due to DNS lookup errors, but if they use an

R: Postgresql 8.4 optimize heavy load

Thank you to everybody and excuse me, first of all. I wrote requests for postgresql (even if connected with Bind-DLZ) in the wrong Group! Thank you! Francesco Da: Sten Carlsen [st...@s-carlsen.dk] Inviato: domenica 18 settembre 2016 0.03 A: Job Cc: bind-users@lists.isc.org Oggetto: Re:

Re: BIND-RPZ and Views

Hi What is the supported/preferred way for implementing slave-rpz's in views? I want to achieve, that view1 has a different policy-configuration (passthru, given, nxdomain..) than the ones configured in view2 using the same slave-rpz-files. If not obligatory, I would not synchronize/transfer