Re: timeouts and negative caching
Hi, > Where do these 300 seconds come from and how can I configure them? I'd like > to drastically reduce them to something like 10 seconds or so to make sure > bind retries to resolve a query shortly after a timeout. I've upgraded my bind version to 9.10.2 and there this timeout-ttl is set to 10 seconds. So some of the developers seem to agree with my idea that 10 seconds is a good value for this. Kind regards, Gerd ___ 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
Re: timeouts and negative caching
Hi Tony, > Look at the lame-ttl option. (though I think the behaviour is more > complicated than the documentation implies) I can report that lame-ttl doesn't help either, the timeout ttl stays at 300 secs. >From reading the manual it seems to me that a "lame server" is something different than a server not responding in time. But as you suggest it may be that the manual does not cover this completely... At least I have perfected the procedure to reproduce the behavior, it just takes me a few minutes now till I get it. Kind regards, Gerd ___ 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
Re: timeouts and negative caching
Hi Mike, On Thursday 11 June 2015 14:37:11 you wrote: > I'm not sure if BIND has a separate tunable for the "timeout vs true > negative answer" scenario you seem to describe, but have you tried setting > max-ncache-ttl very low to see if it affects this? just tried it: max-ncache-ttl doesn't seem to affect the behavior, this mysterious timeout ttl stays at 300 secs. Kind regards, Gerd ___ 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
Re: timeouts and negative caching
Mike Hoskins (michoski) wrote: > I'm not sure if BIND has a separate tunable for the "timeout vs true > negative answer" scenario you seem to describe, but have you tried setting > max-ncache-ttl very low to see if it affects this? Look at the lame-ttl option. (though I think the behaviour is more complicated than the documentation implies) Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon: North 5 to 7. Slight or moderate. Thundery showers later. Good, occasionally poor later. ___ 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
Re: timeouts and negative caching
I'm not sure if BIND has a separate tunable for the "timeout vs true negative answer" scenario you seem to describe, but have you tried setting max-ncache-ttl very low to see if it affects this? On 6/11/15, 9:27 AM, "Gerd v. Egidy" wrote: >Hi, > >I've got a bind running as recursive resolver behind a thin internet >line. >When the line is clogged, requests sometimes time out. When the dns >client >retries the query, bind usually retries the request and eventually >succeeds. >So far so good. > >But now I sometimes see that bind does not retry immediately, but somehow >caches the error for up to 5 minutes (300 secs). The negative answer is >then >given right away, without checking again if the remote server can be >reached >now. > >Here is an example: > >> time dig www.strato.com >; <<>> DiG 9.9.3-P2-RedHat-9.9.3-2.P2.i2n <<>> @localhost www.strato.de >; (1 server found) >;; global options: +cmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43535 >;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > >;; OPT PSEUDOSECTION: >; EDNS: version: 0, flags:; udp: 4096 >;; QUESTION SECTION: >;www.strato.de. IN A > >;; Query time: 4397 msec >;; SERVER: 127.0.0.1#53(127.0.0.1) >;; WHEN: Thu Jun 11 14:14:17 CEST 2015 >;; MSG SIZE rcvd: 42 > >real0m0.007s >user0m0.004s >sys 0m0.000s > >When I look into the bind cache I see this: > >> rndc dumpdb -all >> cat cache_dump.db >[...] >; authauthority >strato.de. 85530 NS ns3.strato.de. >85530 NS ns4.strato.de. >85530 NS ns1.strato.de. >85530 NS ns2.strato.de. >; additional >ns1.strato.de. 85530 A 193.141.40.1 >; additional >ns2.strato.de. 85530 A 81.169.144.234 >; additional >ns3.strato.de. 85530 A 195.122.141.2 >; additional >85530 2a00:e10:2004::2 >; additional >ns4.strato.de. 85530 A 192.166.192.4 >; additional >85530 2a01:238:e100:192::4 >[...] >; >; Address database dump >; >[...] >; ns2.strato.de [v4 TTL 59] [v4 failure] [v6 unexpected] >; ns3.strato.de [v4 TTL 59] [v4 failure] [v6 unexpected] >; ns4.strato.de [v4 TTL 59] [v4 failure] [v6 unexpected] >; ns1.strato.de [v4 TTL 59] [v4 failure] [v6 unexpected] > >I've seen this "[v4 TTL 59]" go up to 300. > >So there must be some kind of "negative caching" which caches timeouts >and, >not like the real negative caching, just active negative results. > >Where do these 300 seconds come from and how can I configure them? I'd >like to >drastically reduce them to something like 10 seconds or so to make sure >bind >retries to resolve a query shortly after a timeout. > >Thank you. > >Kind regards, > >Gerd > >___ >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
timeouts and negative caching
Hi, I've got a bind running as recursive resolver behind a thin internet line. When the line is clogged, requests sometimes time out. When the dns client retries the query, bind usually retries the request and eventually succeeds. So far so good. But now I sometimes see that bind does not retry immediately, but somehow caches the error for up to 5 minutes (300 secs). The negative answer is then given right away, without checking again if the remote server can be reached now. Here is an example: > time dig www.strato.com ; <<>> DiG 9.9.3-P2-RedHat-9.9.3-2.P2.i2n <<>> @localhost www.strato.de ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43535 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.strato.de. IN A ;; Query time: 4397 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 11 14:14:17 CEST 2015 ;; MSG SIZE rcvd: 42 real0m0.007s user0m0.004s sys 0m0.000s When I look into the bind cache I see this: > rndc dumpdb -all > cat cache_dump.db [...] ; authauthority strato.de. 85530 NS ns3.strato.de. 85530 NS ns4.strato.de. 85530 NS ns1.strato.de. 85530 NS ns2.strato.de. ; additional ns1.strato.de. 85530 A 193.141.40.1 ; additional ns2.strato.de. 85530 A 81.169.144.234 ; additional ns3.strato.de. 85530 A 195.122.141.2 ; additional 85530 2a00:e10:2004::2 ; additional ns4.strato.de. 85530 A 192.166.192.4 ; additional 85530 2a01:238:e100:192::4 [...] ; ; Address database dump ; [...] ; ns2.strato.de [v4 TTL 59] [v4 failure] [v6 unexpected] ; ns3.strato.de [v4 TTL 59] [v4 failure] [v6 unexpected] ; ns4.strato.de [v4 TTL 59] [v4 failure] [v6 unexpected] ; ns1.strato.de [v4 TTL 59] [v4 failure] [v6 unexpected] I've seen this "[v4 TTL 59]" go up to 300. So there must be some kind of "negative caching" which caches timeouts and, not like the real negative caching, just active negative results. Where do these 300 seconds come from and how can I configure them? I'd like to drastically reduce them to something like 10 seconds or so to make sure bind retries to resolve a query shortly after a timeout. Thank you. Kind regards, Gerd ___ 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
