6

In my firewall logs I see lots of entries like this.

IN= OUT=eth0 SRC=192.168.1.105 DST=208.67.220.220 LEN=148 TOS=0x00 PREC=0xC0 TTL=64 ID=55705 PROTO=ICMP TYPE=3 CODE=3 [SRC=208.67.220.220 DST=192.168.1.105 LEN=120 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP SPT=53 DPT=25566 LEN=100 ]

It looks like the OpenDNS server at 208.67.220.220 sent my computer some kind of message by UDP from port 53, and my computer tries to respond with an ICMP code type 3 (which my firewall blocks, because I've configured it to block ICMP out, with a few exceptions.)

An ICMP type 3 coming from the OpenDNS servers would make sense, since my computer would try to query their servers, but I don't understand why my computer would try to send this message to their servers, unless their servers were trying to query my own computer for some destination, and I don't understand why their servers would do that.

Is that UDP packet coming from their severs some kind of query?

What's going on here?

Improve this question

2 Answers 2

Reset to default
6

You running Chrome by any chance on the computer with the IP 192.168.1.105? It would appear that Chrome attempts to do a prefetch using ICMP to OpenDNS.

http://productforums.google.com/forum/#!topic/chrome/spzCFoXR7m4

Please see the help reference. It seems turning off DNS pre-fetching is possible.

You can turn it off by following the directions here:

http://www.google.com/support/forum/p/Chrome/thread?tid=7e45d89c67905b20&hl=en

EDIT #1: Follow-up Question

@ProxyNinja asked the following in the comments below:

But ICMP type 3 sounds like a response to a query. How would it be used in a prefetch?

To which I replied:

Doing the ping like this forces the local resolver to do the DNS query, there-by causing it to be resolved ahead of time, would be my guess. The ping is immaterial, it's the DNS resolution that it causes is what they're after.

Improve this answer
7
  • @Braiam - you'd be right, I didn't read the log, only the text of what he was asking about. So then what is the Q???? His computer pinged OpenDNS, so ask the computer about it, has nothing to do with OpenDNS, does it?
    – slm ♦
    Oct 9, 2013 at 0:24
  • @Braiam - see update, that's one possible reason.
    – slm ♦
    Oct 9, 2013 at 0:29
  • Yes, I am running Chrome. But ICMP type 3 sounds like a response to a query. How would it be used in a prefetch?
    – PROXY NINJA
    Oct 9, 2013 at 1:30
  • So you're saying that ICMP type 3 is some kind of ping to OpenDNS, and this will cause the DNS resolver on my machine to fetch an address? If so, then will the DNS resolver on my machine still do this even if my firewall blocks the outgoing ICMP packet?
    – PROXY NINJA
    Oct 9, 2013 at 1:40
  • @PROXYNINJA - All that you're losing with this is the prefetch, so DNS won't already be resolved ahead of time for Chrome without this. I would say "so what" to this feature, so long as you can live with slightly slower DNS resolutions. If you're really worried you can always run something like DNSCache so that you can save on having to do the look ups so frequently.
    – slm ♦
    Oct 9, 2013 at 1:43
2

It's expected behavior for systems running dnsmasq

ICMP type 3 is "Destination Unreachable". That means that your upstream DNS server tried sending you a response, and the port on your system for receiving the port had closed before the response came.

You mention in your comments in the other answer that you're running dnsmasq. By default, when dnsmasq has multiple upstream servers defined, every so many requests it will send its query upstream to all of them. This helps it figure out which servers are currently responding and which are fastest. Generally, after it gets the response from the fastest one, it closes the port. If any further responses come from the other DNS servers, there's no longer an application listening for them, so the system that dnsmasq is on replies back with a "Destination Unreachable" ICMP message. It shouldn't actually be causing any problems, other then that tiny bit of extra traffic showing up in your logs.

For more information, see the comments in Debian bug #580064, where somebody reports this issue and the principal developer of dnsmasq replies that it's expected behavior.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .