Re: [squid-users] 3.4.0.1 dnsreq statistics question
* Eliezer Croitoru elie...@ngtech.co.il: On 07/30/2013 05:56 PM, Ralf Hildebrandt wrote: Nope. Just asking why the stats suddenly would look different. I'll check the other machines in the cluster IS it a bind\named DNS server?? Yes -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: [squid-users] 3.4.0.1 dnsreq statistics question
* Amos Jeffries squ...@treenet.co.nz: It's most likely to be the internet DNS infrastructure that is the problem compared to local mDNS. Only if the NS being used is something remote. Such as Googles resolvers. The recommended practice of using a local recursive resolver That's what we're using. will send a SERVFAIL response back to Squid if there is any kind of Internet DNS failures. Which does get recorded as a received response even if it is not useful. Amos -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: [squid-users] 3.4.0.1 dnsreq statistics question
* Amos Jeffries squ...@treenet.co.nz: So I would see *.local queries in the query log on the local caching DNS on the machine? I would expect to yes. At least that was the behaviour when I tested it. - lookup for invalid.local in mDNS server - timeout - lookup for invalid.local in local NS server - NXDOMAIN The Query log is not showing any of these Ah sorry I steered a bit wrong. Squid will not add the .local part itself. Resolv.conf or equivalent search list settings are still required to do that mapping part. The mDNS only steps in with a different resolver if the domain tail matches .local. OK, since we didn't configure this, it won't be queried. What does the idns cache manager report say about #QUERIES vs #REPLIES on each of your NS ? idns cache manager? Is that a function of Squid or in my local caching DNS? -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: [squid-users] 3.4.0.1 dnsreq statistics question
* Amos Jeffries squ...@treenet.co.nz: Aha. Digging around in the code I found another way that the queries and replies counters may be getting separated. = all queries are recorded at the point they are sent. = replies are recorded only if the nameserver they are received from is a known NS. So if you have ignore_unknown_nameservers set to ON, the difference would be the replies dropped from unknown servers. ignore_unknown_nameservers defaults to ON NP: I am still suspicious that this may be related to mDNS, since I think the mDNS responses come back form the LAN machines as unicast replies and would hit that known/unknown security check. So if I set ignore_unknown_nameservers to OFF, then the numbers would change? -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: [squid-users] 3.4.0.1 dnsreq statistics question
On 31/07/2013 8:36 p.m., Ralf Hildebrandt wrote: * Amos Jeffries squ...@treenet.co.nz: So I would see *.local queries in the query log on the local caching DNS on the machine? I would expect to yes. At least that was the behaviour when I tested it. - lookup for invalid.local in mDNS server - timeout - lookup for invalid.local in local NS server - NXDOMAIN The Query log is not showing any of these Ah sorry I steered a bit wrong. Squid will not add the .local part itself. Resolv.conf or equivalent search list settings are still required to do that mapping part. The mDNS only steps in with a different resolver if the domain tail matches .local. OK, since we didn't configure this, it won't be queried. What does the idns cache manager report say about #QUERIES vs #REPLIES on each of your NS ? idns cache manager? Is that a function of Squid or in my local caching DNS? It is one of the squid cachmgr reports called idns. Amos
Re: [squid-users] 3.4.0.1 dnsreq statistics question
* Amos Jeffries squ...@treenet.co.nz: What does the idns cache manager report say about #QUERIES vs #REPLIES on each of your NS ? idns cache manager? Is that a function of Squid or in my local caching DNS? It is one of the squid cachmgr reports called idns. Squid Object Cache: Version 3.4.0.1 Start Time:Tue, 30 Jul 2013 19:47:29 GMT Current Time:Wed, 31 Jul 2013 12:32:56 GMT ... Internal DNS Statistics: The Queue: DELAY SINCE ID SIZE SENDS FIRST SEND LAST SEND -- - -- - 0x5f4e 45 1 0.004 0.004 0x84dd 45 1 0.004 0.004 0x0d60 42 1 0.091 0.091 0x06f1 42 1 0.091 0.091 0x9319 45 1 0.193 0.193 0x2bb5 45 1 0.193 0.193 0x17d9 43 2 5.584 0.246 0x5bdb 43 2 5.584 0.246 0xe53d 42 1 0.267 0.267 0x0a8e 42 1 0.267 0.267 0xbcf4 44 1 0.666 0.666 0xe3bc 44 1 0.666 0.666 0x2731 43 1 1.010 1.010 0x64af 43 1 1.010 1.010 0xc61e 44 1 1.015 1.015 0xf283 44 1 1.015 1.015 0x561d 43 1 1.159 1.159 0x585c 43 1 1.159 1.159 0xf1c4 45 1 1.196 1.196 0xe1ab 45 1 1.196 1.196 0x4bac 44 1 1.240 1.240 0xbdd5 44 1 1.240 1.240 0x792c 44 1 1.241 1.241 0xd608 44 1 1.241 1.241 0xcab5 43 1 1.264 1.264 0x20a7 43 1 1.264 1.264 0x4c1c 43 1 1.299 1.299 0x591e 43 1 1.299 1.299 0xe1d2 43 1 1.301 1.301 0x4343 43 1 1.301 1.301 0x5854 44 1 2.674 2.674 0xe0f7 44 1 2.674 2.674 0x51b7 45 1 2.708 2.708 0xd992 45 1 2.708 2.708 0x6426 45 1 2.836 2.836 0x7000 45 1 2.836 2.836 0xf320 43 1 3.414 3.414 0x5885 43 1 3.414 3.414 0x3ed4 42 1 3.872 3.872 0x08d9 42 1 3.872 3.872 0x157e 42 1 3.993 3.993 0xf0ff 42 1 3.993 3.993 0x08c8 45 1 4.024 4.024 0xbaa0 45 1 4.024 4.024 0x46af 45 1 4.027 4.027 0x229b 45 1 4.027 4.027 0xf611 45 1 4.101 4.101 0xb340 45 1 4.101 4.101 0xe821 44 1 4.199 4.199 0xc9eb 44 1 4.199 4.199 0x7ec2 44 1 4.270 4.270 0xac49 44 1 4.270 4.270 0xed91 45 1 4.529 4.529 0x6991 45 1 4.529 4.529 0x970d 44 1 4.947 4.947 0x40ce 44 1 4.947 4.947 0x0ffa 44 1 5.027 5.027 0xebb7 44 1 5.027 5.027 0x19b0 43 1 5.171 5.171 0x8113 43 1 5.171 5.171 0x0cf4 42 1 5.204 5.204 0x2956 42 1 5.204 5.204 DNS jumbo-grams: not working Nameservers: IP ADDRESS # QUERIES # REPLIES Type -- - - 224.0.0.251 122256 0 multicast 127.0.0.1320995317586 recurse 141.42.2.223576 332 recurse 141.42.3.333520 1527 recurse Rcode Matrix: RCODE ATTEMPT1 ATTEMPT2 ATTEMPT3 PROBLEM 0 47079656 : Success 1000 : Packet Format Error 2 392 375 323 : DNS Server Failure 33038900 : Non-Existent Domain 4000 : Not Implemented 5000 : Query Refused 6000 : Name Exists when it should not -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: [squid-users] 3.4.0.1 dnsreq statistics question
* Ralf Hildebrandt ralf.hildebra...@charite.de: Nameservers: IP ADDRESS # QUERIES # REPLIES Type -- - - 224.0.0.251 122256 0 multicast Huh? The numbers account for what I'm seeing in my graphs. And indeed, I'm seeing queries on the net: % tcpdump -i eth1 host 224.0.0.251 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 14:41:00.546196 IP proxy-cvk-2-e.charite.de.49093 224.0.0.251.mdns: 44683+ PTR (QM)? 234.129.89.95.in-addr.arpa. (44) 14:41:00.546796 IP proxy-cvk-2-e.charite.de.49093 224.0.0.251.mdns: 15065+ PTR (QM)? 234.129.89.95.in-addr.arpa. (44) 14:41:00.879966 IP proxy-cvk-1-e.charite.de.50277 224.0.0.251.mdns: 38706+ PTR (QM)? 139.203.238.77.in-addr.arpa. (45) 14:41:00.880286 IP proxy-cvk-1-e.charite.de.50277 224.0.0.251.mdns: 3929+ PTR (QM)? 139.203.238.77.in-addr.arpa. (45) So what we are seeing here are two proxies querying IP addresses (client IP addresses?) using mDNS. But why? I don't have avahi running at all. proxy-cvk-1-e.charite.de.50277 points to squid: # netstat -tulpen |grep 50277 udp0 0 0.0.0.0:50277 0.0.0.0:* 13 1393747784 7832/squid According to the release notes: There is no additional or special configuration required. The multicast DNS group IP addresses for IPv4 and IPv6 resolving are added to the set of available DNS resolvers and used automatically for domain names ending in .local before attempting a secondary resolution on the configured resolvers. Domains without .local are resolved using only the configured DNS resolvers. Hm, so everything is working as expected. Can it be turned off? -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: [squid-users] 3.4.0.1 dnsreq statistics question
On 1/08/2013 12:56 a.m., Ralf Hildebrandt wrote: * Ralf Hildebrandt ralf.hildebra...@charite.de: Nameservers: IP ADDRESS # QUERIES # REPLIES Type -- - - 224.0.0.251 122256 0 multicast Huh? The numbers account for what I'm seeing in my graphs. And indeed, I'm seeing queries on the net: % tcpdump -i eth1 host 224.0.0.251 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 14:41:00.546196 IP proxy-cvk-2-e.charite.de.49093 224.0.0.251.mdns: 44683+ PTR (QM)? 234.129.89.95.in-addr.arpa. (44) 14:41:00.546796 IP proxy-cvk-2-e.charite.de.49093 224.0.0.251.mdns: 15065+ PTR (QM)? 234.129.89.95.in-addr.arpa. (44) 14:41:00.879966 IP proxy-cvk-1-e.charite.de.50277 224.0.0.251.mdns: 38706+ PTR (QM)? 139.203.238.77.in-addr.arpa. (45) 14:41:00.880286 IP proxy-cvk-1-e.charite.de.50277 224.0.0.251.mdns: 3929+ PTR (QM)? 139.203.238.77.in-addr.arpa. (45) So what we are seeing here are two proxies querying IP addresses (client IP addresses?) using mDNS. But why? Oh. Sorry I had forgotten .arpa. The mDNS spec simply says all rDNS should go through mDNS as well so local servers are able to respond with their hostnames if any of their IPs are requested. I don't have avahi running at all. proxy-cvk-1-e.charite.de.50277 points to squid: # netstat -tulpen |grep 50277 udp0 0 0.0.0.0:50277 0.0.0.0:* 13 1393747784 7832/squid According to the release notes: There is no additional or special configuration required. The multicast DNS group IP addresses for IPv4 and IPv6 resolving are added to the set of available DNS resolvers and used automatically for domain names ending in .local before attempting a secondary resolution on the configured resolvers. Domains without .local are resolved using only the configured DNS resolvers. Hm, so everything is working as expected. Can it be turned off? Not in the current release. Here is a patch which enables that and some extra details in the idns report: http://treenet.co.nz/projects/squid/patches/mdns_configurable_mk1.patch Amos
Re: [squid-users] 3.4.0.1 dnsreq statistics question
* Amos Jeffries squ...@treenet.co.nz: Hm, so everything is working as expected. Can it be turned off? Not in the current release. Here is a patch which enables that and some extra details in the idns report: http://treenet.co.nz/projects/squid/patches/mdns_configurable_mk1.patch I applied it to 3.4.0.1, and it's working :) Internal DNS Statistics: The Queue: DELAY SINCE ID SIZE SENDS FIRST SEND LAST SEND M FQDN -- - -- - - DNS jumbo-grams: not working Nameservers: IP ADDRESS # QUERIES # REPLIES Type -- - - 127.0.0.1 1182 1181 recurse 141.42.2.22 0 0 recurse 141.42.3.33 0 0 recurse Rcode Matrix: RCODE ATTEMPT1 ATTEMPT2 ATTEMPT3 PROBLEM 0 107700 : Success 1000 : Packet Format Error 2000 : DNS Server Failure 3 10400 : Non-Existent Domain 4000 : Not Implemented 5000 : Query Refused 6000 : Name Exists when it should not 7000 : RR Set Exists when it should not 8000 : RR Set that should exist does not 9000 : Server Not Authoritative for zone 10000 : Name not contained in zone 16000 : Bad OPT Version or TSIG Signature Failure Search list: charite.de -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
[squid-users] 3.4.0.1 dnsreq statistics question
I had good results replacing 3.3.8 with 3.4.0.1 - no changes to the config were needed. One interesting observation: The dnsreq statistics are different. With 3.3.8 the graphs for requests and replies were identical. Plotted on top of each other -- only one graph could be seen. Since switching to I'm seeing MORE requests than replies. Not much, but enough for the graphs to be seen individually. Currently I'm seeing 10.17 requests and 8.21 replies per second. Is this to be expected? Graph: http://www.arschkrebs.de/bugs/dnsreq1d.png on the left side you can see the point in time I changed the squid versions. -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: [squid-users] 3.4.0.1 dnsreq statistics question
On 30/07/2013 11:15 p.m., Ralf Hildebrandt wrote: I had good results replacing 3.3.8 with 3.4.0.1 - no changes to the config were needed. One interesting observation: The dnsreq statistics are different. With 3.3.8 the graphs for requests and replies were identical. Plotted on top of each other -- only one graph could be seen. Since switching to I'm seeing MORE requests than replies. Not much, but enough for the graphs to be seen individually. Currently I'm seeing 10.17 requests and 8.21 replies per second. Is this to be expected? Yes and No. Yes, 3.4 added mDNS support which have no particular guarantee of getting any response. If you do not have mDNS setup the .local requests will timeout instead, before moving on to the global resolution methods. No, because the above event should only show up on single-label domain names in URL or Host: header. And if you do have .local mDNS setup in the network most of them should be getting responses anyway. Amos
Re: [squid-users] 3.4.0.1 dnsreq statistics question
On 07/30/2013 03:15 PM, Amos Jeffries wrote: Yes and No. Yes, 3.4 added mDNS support which have no particular guarantee of getting any response. If you do not have mDNS setup the .local requests will timeout instead, before moving on to the global resolution methods. No, because the above event should only show up on single-label domain names in URL or Host: header. And if you do have .local mDNS setup in the network most of them should be getting responses anyway. Amos It's most likely to be the internet DNS infrastructure that is the problem compared to local mDNS. In many cases you can get no response when querying a DNS if you do have a route problem for a sec. Once a BGP session ended it takes couple secs or MS to get the path correctly. You can test it using a local DNS server that will be a proxy that response in any case and then see if the DNS is responding with a respond or the route is the problem. This way all the tests will be done on the local network rather then over the INTERNET and then you can ask the next person in the chain in order to get a deeper response. Eliezer
Re: [squid-users] 3.4.0.1 dnsreq statistics question
* Eliezer Croitoru elie...@ngtech.co.il: It's most likely to be the internet DNS infrastructure that is the problem compared to local mDNS. In many cases you can get no response when querying a DNS if you do have a route problem for a sec. And the routing problems suddenly started when I installed 3.4.0.1? Once a BGP session ended it takes couple secs or MS to get the path correctly. You can test it using a local DNS server that will be a proxy that response in any case and then see if the DNS is responding with a respond or the route is the problem. We're using a local cache on all proxies. This way all the tests will be done on the local network rather then over the INTERNET and then you can ask the next person in the chain in order to get a deeper response. Eliezer -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: [squid-users] 3.4.0.1 dnsreq statistics question
* Amos Jeffries squ...@treenet.co.nz: On 30/07/2013 11:15 p.m., Ralf Hildebrandt wrote: I had good results replacing 3.3.8 with 3.4.0.1 - no changes to the config were needed. One interesting observation: The dnsreq statistics are different. With 3.3.8 the graphs for requests and replies were identical. Plotted on top of each other -- only one graph could be seen. Since switching to I'm seeing MORE requests than replies. Not much, but enough for the graphs to be seen individually. Currently I'm seeing 10.17 requests and 8.21 replies per second. Is this to be expected? Yes and No. Yes, 3.4 added mDNS support which have no particular guarantee of getting any response. If you do not have mDNS setup the .local requests will timeout instead, before moving on to the global resolution methods. So I would see *.local queries in the query log on the local caching DNS on the machine? No, because the above event should only show up on single-label domain names in URL or Host: header. Like accesssing http://www ? And if you do have .local mDNS setup in the network We don't use that in the server networks. most of them should be getting responses anyway. -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: [squid-users] 3.4.0.1 dnsreq statistics question
On 07/30/2013 05:18 PM, Ralf Hildebrandt wrote: * Eliezer Croitoru elie...@ngtech.co.il: It's most likely to be the internet DNS infrastructure that is the problem compared to local mDNS. In many cases you can get no response when querying a DNS if you do have a route problem for a sec. And the routing problems suddenly started when I installed 3.4.0.1? Well not related to squid directly but yes it can be possible since in the INTERNET there are a lot of packets that just drops.. Also I do not know who is the person in charge of the ROUTING but it can be traced using a simple sampling and some NAGIOS dig and ping checks... Once a BGP session ended it takes couple secs or MS to get the path correctly. You can test it using a local DNS server that will be a proxy that response in any case and then see if the DNS is responding with a respond or the route is the problem. We're using a local cache on all proxies. DNS cache??? Try to force the DNS server to bind specific port to differentiate the PROXY requests to the DNS requests.. Just suggesting some really good test that can be done easily to minimize the damage to specific points. Eliezer This way all the tests will be done on the local network rather then over the INTERNET and then you can ask the next person in the chain in order to get a deeper response. Eliezer
Re: [squid-users] 3.4.0.1 dnsreq statistics question
* Eliezer Croitoru elie...@ngtech.co.il: Well not related to squid directly but yes it can be possible since in the INTERNET there are a lot of packets that just drops.. But that hasn't changed... I should have observed the same drops before going to 3.4.x - looking at the numbers right now: 30 requests/s 20 replies/s That would mean 33.3% percent unanswered queries. At the same time the IP Cache hitsmisses and FQDN cache hitsmisses statistics look like before. We're using a local cache on all proxies. DNS cache??? Yep. Try to force the DNS server to bind specific port to differentiate the PROXY requests to the DNS requests.. The proxy is the only program quering the local DNS server. It's bound to 127.0.0.1 I'm looking at the query.log, but I'm not seeing any queries to .local names at all. Maybe some new code path is not adding to the statistics? -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: [squid-users] 3.4.0.1 dnsreq statistics question
On 07/30/2013 05:33 PM, Ralf Hildebrandt wrote: The proxy is the only program quering the local DNS server. It's bound to 127.0.0.1 I'm looking at the query.log, but I'm not seeing any queries to .local names at all. Maybe some new code path is not adding to the statistics? Like what? OK so the dns only queryies are not the .local ons?? in this case you can start monitoring your network infrastructure to make sure what happens just to make sure that the infrastructure works fine. it's a simple task.. and it will make a stronger argument then just plain old statistics. it would have long history. Do you see any real life threatening situation that it can affect.. the DNS dropping packets? I think that the F5 or CTRL-F5 keys should be right there to make sure what ever problems are outhere should be enough for most users cases. Eliezer
Re: [squid-users] 3.4.0.1 dnsreq statistics question
* Eliezer Croitoru elie...@ngtech.co.il: On 07/30/2013 05:33 PM, Ralf Hildebrandt wrote: The proxy is the only program quering the local DNS server. It's bound to 127.0.0.1 I'm looking at the query.log, but I'm not seeing any queries to .local names at all. Maybe some new code path is not adding to the statistics? Like what? OK so the dns only queryies are not the .local ons?? Exactly, there are only queries like internal IPs external domainnames: 30-Jul-2013 16:33:42.777 client 127.0.0.1#43716: query: 249.138.42.141.in-addr.arpa IN PTR + (127.0.0.1) 30-Jul-2013 16:33:42.777 client 127.0.0.1#43716: query: 249.138.42.141.in-addr.arpa IN PTR + (127.0.0.1) 30-Jul-2013 16:33:42.777 client 127.0.0.1#43716: query: 249.138.42.141.in-addr.arpa IN PTR + (127.0.0.1) 30-Jul-2013 16:33:42.777 client 127.0.0.1#43716: query: 249.138.42.141.in-addr.arpa IN PTR + (127.0.0.1) 30-Jul-2013 16:33:42.777 client 127.0.0.1#43716: query: 249.138.42.141.in-addr.arpa IN PTR + (127.0.0.1) 30-Jul-2013 16:33:42.777 client 127.0.0.1#43716: query: 249.138.42.141.in-addr.arpa IN PTR + (127.0.0.1) 30-Jul-2013 16:33:42.777 client 127.0.0.1#43716: query: 249.138.42.141.in-addr.arpa IN PTR + (127.0.0.1) 30-Jul-2013 16:33:42.778 client 127.0.0.1#43716: query: 249.138.42.141.in-addr.arpa IN PTR + (127.0.0.1) 30-Jul-2013 16:33:42.778 client 127.0.0.1#43716: query: 227.56.248.78.in-addr.arpa IN PTR + (127.0.0.1) 30-Jul-2013 16:33:42.778 client 127.0.0.1#43716: query: 249.138.42.141.in-addr.arpa IN PTR + (127.0.0.1) 30-Jul-2013 16:33:42.778 client 127.0.0.1#43716: query: 249.138.42.141.in-addr.arpa IN PTR + (127.0.0.1) 30-Jul-2013 16:33:42.781 client 127.0.0.1#43716: query: 227.56.248.78.in-addr.arpa IN PTR + (127.0.0.1) 30-Jul-2013 16:33:42.826 client 127.0.0.1#43716: query: www.viewster.com IN A + (127.0.0.1) 30-Jul-2013 16:33:42.901 client 127.0.0.1#43716: query: banner.congstar.de IN A + (127.0.0.1) 30-Jul-2013 16:33:42.934 client 127.0.0.1#43716: query: n28.ad.ad-srv.net IN A + (127.0.0.1) 30-Jul-2013 16:33:42.935 client 127.0.0.1#43716: query: platform.twitter.com IN A + (127.0.0.1) 30-Jul-2013 16:33:43.004 client 127.0.0.1#43716: query: www.googletagmanager.com IN A + (127.0.0.1) 30-Jul-2013 16:33:43.168 client 127.0.0.1#43716: query: cdn.gmxpro.net IN A + (127.0.0.1) 30-Jul-2013 16:33:43.177 client 127.0.0.1#43716: query: divaag.vo.llnwd.net IN A + (127.0.0.1) 30-Jul-2013 16:33:43.312 client 127.0.0.1#43716: query: aidps.atdmt.com IN A + (127.0.0.1) 30-Jul-2013 16:33:43.327 client 127.0.0.1#43716: query: dc8.s317.meetrics.net IN A + (127.0.0.1) 30-Jul-2013 16:33:43.337 client 127.0.0.1#43716: query: viewster.ivwbox.de IN A + (127.0.0.1) 30-Jul-2013 16:33:43.372 client 127.0.0.1#43716: query: viewster.tv IN A + (127.0.0.1) 30-Jul-2013 16:33:43.456 client 127.0.0.1#43716: query: us-mg5.mail.yahoo.com IN A + (127.0.0.1) 30-Jul-2013 16:33:43.676 client 127.0.0.1#43716: query: download.cdn.mozilla.net IN A + (127.0.0.1) in this case you can start monitoring your network infrastructure to make sure what happens just to make sure that the infrastructure works fine. Everything is working fine is already being monitored. it's a simple task.. and it will make a stronger argument then just plain old statistics. They are part of the monitoring. If they look different, I tend to ask questions: Like: http://www.squid-cache.org/mail-archive/squid-users/200712/0465.html (broken memory statistics in 3.0.x) Or: http://comments.gmane.org/gmane.comp.web.squid.general/97869 (sudden increase of the HttpErrors counter with 3.2.0.19 -- due to a change of what counts as an error page) it would have long history. Do you see any real life threatening situation that it can affect. Nope. Just asking why the stats suddenly would look different. I'll check the other machines in the cluster -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: [squid-users] 3.4.0.1 dnsreq statistics question
On 31/07/2013 2:22 a.m., Ralf Hildebrandt wrote: * Amos Jeffries squ...@treenet.co.nz: On 30/07/2013 11:15 p.m., Ralf Hildebrandt wrote: I had good results replacing 3.3.8 with 3.4.0.1 - no changes to the config were needed. One interesting observation: The dnsreq statistics are different. With 3.3.8 the graphs for requests and replies were identical. Plotted on top of each other -- only one graph could be seen. Since switching to I'm seeing MORE requests than replies. Not much, but enough for the graphs to be seen individually. Currently I'm seeing 10.17 requests and 8.21 replies per second. Is this to be expected? Yes and No. Yes, 3.4 added mDNS support which have no particular guarantee of getting any response. If you do not have mDNS setup the .local requests will timeout instead, before moving on to the global resolution methods. So I would see *.local queries in the query log on the local caching DNS on the machine? I would expect to yes. At least that was the behaviour when I tested it. - lookup for invalid.local in mDNS server - timeout - lookup for invalid.local in local NS server - NXDOMAIN No, because the above event should only show up on single-label domain names in URL or Host: header. Like accesssing http://www ? Ah sorry I steered a bit wrong. Squid will not add the .local part itself. Resolv.conf or equivalent search list settings are still required to do that mapping part. The mDNS only steps in with a different resolver if the domain tail matches .local. And if you do have .local mDNS setup in the network We don't use that in the server networks. Okay. Then mDNS should be irrrelevant. What does the idns cache manager report say about #QUERIES vs #REPLIES on each of your NS ? Amos
Re: [squid-users] 3.4.0.1 dnsreq statistics question
Aha. Digging around in the code I found another way that the queries and replies counters may be getting separated. = all queries are recorded at the point they are sent. = replies are recorded only if the nameserver they are received from is a known NS. So if you have ignore_unknown_nameservers set to ON, the difference would be the replies dropped from unknown servers. NP: I am still suspicious that this may be related to mDNS, since I think the mDNS responses come back form the LAN machines as unicast replies and would hit that known/unknown security check. Amos
Re: [squid-users] 3.4.0.1 dnsreq statistics question
On 31/07/2013 2:15 a.m., Eliezer Croitoru wrote: On 07/30/2013 03:15 PM, Amos Jeffries wrote: Yes and No. Yes, 3.4 added mDNS support which have no particular guarantee of getting any response. If you do not have mDNS setup the .local requests will timeout instead, before moving on to the global resolution methods. No, because the above event should only show up on single-label domain names in URL or Host: header. And if you do have .local mDNS setup in the network most of them should be getting responses anyway. Amos It's most likely to be the internet DNS infrastructure that is the problem compared to local mDNS. Only if the NS being used is something remote. Such as Googles resolvers. The recommended practice of using a local recursive resolver will send a SERVFAIL response back to Squid if there is any kind of Internet DNS failures. Which does get recorded as a received response even if it is not useful. Amos
Re: [squid-users] 3.4.0.1 dnsreq statistics question
On 07/30/2013 07:25 PM, Amos Jeffries wrote: Aha. Digging around in the code I found another way that the queries and replies counters may be getting separated. = all queries are recorded at the point they are sent. = replies are recorded only if the nameserver they are received from is a known NS. So if you have ignore_unknown_nameservers set to ON, the difference would be the replies dropped from unknown servers. NP: I am still suspicious that this may be related to mDNS, since I think the mDNS responses come back form the LAN machines as unicast replies and would hit that known/unknown security check. Amos I really suspect that a recursive lookup of the bind or whatever server would do that. If it can be resolved I would expect it to not work? Eliezer
