Amos Jeffries wrote > The core issue is the speed at which that service rotates its response > IP lists, which is directly related to each request going to entirely > different server in their farm. Simply having a single (and maybe more > sane regarding TTLs) resolver as a networks focal point for the traffic > before it reaches out to the Google service seems to bring sanity back > to the performance. Ok, thanks. mmm... and what you think about this dig -x google.com ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> -x google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25260 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;com.google.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: in-addr.arpa. 900 IN SOA b.in-addr-servers.arpa. nstld.iana.org. 2017042647 1800 900 604800 3600 ;; Query time: 1 msec ;; SERVER: 192.168.1.222#53(192.168.1.222) ;; WHEN: lun jun 05 12:37:03 ART 2017 ;; MSG SIZE rcvd: 120 We have, little time? about 15', this is a problem, dont you think? Or im using bad dig?? what would be a good value??? Thanks againg. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/this-config-is-ok-is-ok-the-order-tp4682631p4682677.html Sent from the Squid - Users mailing list archive at Nabble.com. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
