Hello,
safebrowsing-cache.google.com is checked from both Google Toolbar included by default in Firefox 3 and on Google Chrome Navigator. Google Toolbar is also available on IE, etc.
When the query reaches the DNS of the ISP it will reply with a DNS TCP reply if minimal-responses is no (default on Bind9) or with a small UDP DSN reply if minimal-responses is yes.
I recommend that all ISP use minimal-responses yes or equivalent on their DNS server. This will save bandwidth and avoid DNS TCP reply to be blocked in a Firewall in the path.
Best Regards, Guy Baconniere
http://www.divideandconquer.se/2009/06/25/firefox-30-freezes-waiting-to-reso...
Add “minimal-responses yes;” in your bind9 configuration or ask your ISP to do so. /etc/bind/named.conf.options options { // … // only add records to the authority and additional data sections when required minimal-responses yes; };
By doing this Google’s safebrowsing-cache.google.com will fit in a standard UDP DNS packet otherwise with additional section it will be TCP DNS packet. check the result with or without minimal-responses of dig safebrowsing-cache.google.com
With minimal-responses no (default on Bind9)
IP (tos 0×0, ttl 64, id 40627, offset 0, flags [none], proto UDP (17), length 75) 127.0.0.1.49553 > 127.0.0.1.53: [bad udp cksum 6429!] 40815+ A? safebrowsing-cache.google.com. (47) IP (tos 0×0, ttl 64, id 40628, offset 0, flags [none], proto UDP (17), length 526) 127.0.0.1.53 > 127.0.0.1.49553: 40815| q: A? safebrowsing-cache.google.com. 25/2/0 safebrowsing-cache.google.com.[|domain] IP (tos 0×0, ttl 64, id 4337, offset 0, flags [DF], proto TCP (6), length 60) 127.0.0.1.57552 > 127.0.0.1.53: S, cksum 0×30e4 (correct), 272739230:272739230(0) win 32792 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 127.0.0.1.53 > 127.0.0.1.57552: S, cksum 0×6453 (correct), 281541131:281541131(0) ack 272739231 win 32768 IP (tos 0×0, ttl 64, id 4338, offset 0, flags [DF], proto TCP (6), length 52) 127.0.0.1.57552 > 127.0.0.1.53: ., cksum 0×4b76 (correct), 1:1(0) ack 1 win 513 IP (tos 0×0, ttl 64, id 4339, offset 0, flags [DF], proto TCP (6), length 101) 127.0.0.1.57552 > 127.0.0.1.53: P 1:50(49) ack 1 win 513 5198+[|domain] IP (tos 0×0, ttl 64, id 16739, offset 0, flags [DF], proto TCP (6), length 52) 127.0.0.1.53 > 127.0.0.1.57552: ., cksum 0×4b46 (correct), 1:1(0) ack 50 win 512 14:44:32.883449 IP (tos 0×0, ttl 64, id 16740, offset 0, flags [DF], proto TCP (6), length 632) 127.0.0.1.53 > 127.0.0.1.57552: P 1:581(580) ack 50 win 512 5198 q:[|domain] IP (tos 0×0, ttl 64, id 4340, offset 0, flags [DF], proto TCP (6), length 52) 127.0.0.1.57552 > 127.0.0.1.53: ., cksum 0×48ef (correct), 50:50(0) ack 581 win 531 IP (tos 0×0, ttl 64, id 4341, offset 0, flags [DF], proto TCP (6), length 52) 127.0.0.1.57552 > 127.0.0.1.53: F, cksum 0×48ee (correct), 50:50(0) ack 581 win 531 IP (tos 0×0, ttl 64, id 16741, offset 0, flags [DF], proto TCP (6), length 52) 127.0.0.1.53 > 127.0.0.1.57552: F, cksum 0×4900 (correct), 581:581(0) ack 51 win 512 IP (tos 0×0, ttl 64, id 4342, offset 0, flags [DF], proto TCP (6), length 52) 127.0.0.1.57552 > 127.0.0.1.53: ., cksum 0×48ed (correct), 51:51(0) ack 582 win 531
With minimal-responses yes
IP (tos 0×0, ttl 64, id 40623, offset 0, flags [none], proto UDP (17), length 75) 127.0.0.1.40215 > 127.0.0.1.53: [bad udp cksum 8a13!] 55747+ A? safebrowsing-cache.google.com. (47) IP (tos 0×0, ttl 64, id 40624, offset 0, flags [none], proto UDP (17), length 494) 127.0.0.1.53 > 127.0.0.1.40215: 55747 q: A? safebrowsing-cache.google.com. 25/0/0 safebrowsing-cache.google.com.[|domain]
Best Regards, Guy Baconniere
Guy Baconniere :
I recommend that all ISP use minimal-responses yes or equivalent on their DNS server. This will save bandwidth and avoid DNS TCP reply to be blocked in a Firewall in the path.
Hello, Thanks for the information, but did you/someone notice any side effects of "minimal-responses" ?
Thanks,
Marc Hauswirth
Guy Baconniere wrote:
When the query reaches the DNS of the ISP it will reply with a DNS TCP reply if minimal-responses is no (default on Bind9) or with a small UDP DSN reply if minimal-responses is yes.
I can't quite see how that would be correct. When a resolver issues a query with UDP, it will expect a reply (minimal or not) via UDP. Only if it does not get a useful answer via UDP will it change and try a TCP query.
I recommend that all ISP use minimal-responses yes or equivalent on their DNS server. This will save bandwidth and avoid DNS TCP reply to be blocked in a Firewall in the path.
When the client has issued a TCP query, any half-way decent firewall will know not to block the reply.
/Per
Per Jessen wrote:
Guy Baconniere wrote:
When the query reaches the DNS of the ISP it will reply with a DNS TCP reply if minimal-responses is no (default on Bind9) or with a small UDP DSN reply if minimal-responses is yes.
I can't quite see how that would be correct. When a resolver issues a query with UDP, it will expect a reply (minimal or not) via UDP. Only if it does not get a useful answer via UDP will it change and try a TCP query.
Ah, I see that is exactly what you meant. I guess some bandwidth could be saved, but I wonder if it's worth bothering unless your DNS server is about to croak from load.
/Per
Hello,
Marc Hauswirth wrote:
Thanks for the information, but did you/someone notice any side effects of "minimal-responses" ?
I found the following posts on the topic
http://blog.pantek.com/opensores/labels/minimal-responses.html http://archive.netbsd.se/?ml=bind-users&a=2007-06&t=4487849 https://lists.isc.org/pipermail/bind-users/2005-February/055443.html
http://forums.theplanet.com/lofiversion/index.php/t85037.html http://directadmin.com/forum/showthread.php?t=25532
Per Jessen wrote:
/ I can't quite see how that would be correct. When a resolver issues a
/>/ query with UDP, it will expect a reply (minimal or not) via UDP. Only />/ if it does not get a useful answer via UDP will it change and try a />/ TCP query. />
Ah, I see that is exactly what you meant. I guess some bandwidth could be saved, but I wonder if it's worth bothering unless your DNS server is about to croak from load.
That the point we had our DNS servers very busy because it keep on receiving invalid TCP DNS SYN win=0 then a RST from all our Colubris when the cache DNS is enabled. Colubris seems to have a bug with TCP DNS triggered by users using Google Safe Browsing (Firefox 3, Chrome, etc).
netstat -sn "152891264 resets received for embryonic SYN_RECV sockets"
The workaround was to enable minimal-responses so the reply of safebrowsing-cache.google.com fit in an UDP packet and keep the cache from trying with TCP.
When the client has issued a TCP query, any half-way decent firewall will know not to block the reply.
We didn't have any issue with filtering only with the DoS of SYN coming from all our Colubris to our main firewall. We reach
I talk about blocking on Firewall because I found a post related to the issue. http://www.divideandconquer.se/2009/06/25/firefox-30-freezes-waiting-to-reso...
Best Regards, Guy Baconniere
-
Guy Baconniere -
Marc Hauswirth -
Per Jessen