I noticed something really really strange I can't figure out, while wiresharking both my 2 Ubuntus 14.04 LTS : somehow randomly, Ubuntu seems to drop some incomming DNS replies. This happens both for IPv4 and IPv6, with ip(6)tables -P INPUT ACCEPT / ip(6)tables -P OUTPUT ACCEPT. Here are the Wireshark records ( obfuscated ) :

Internet Control Message Protocol / Type: 3 (Destination unreachable) / Code: 3 (Port unreachable) Internet Protocol Version 4, Src: (, Dst: ( User Datagram Protocol, Src Port: domain (53), Dst Port: 26305 (26305)

ICMPv6 / Type: Destination Unreachable (1) / Code: 4 (Port unreachable) Internet Protocol Version 6, Src: 2620:0:ccc::2 (2620:0:ccc::2), Dst: 2001:db8:0:2::200 (2001:db8:0:2::200) User Datagram Protocol, Src Port: domain (53), Dst Port: 60285 (60285)

This happens at random times, only a few replies dropped while a big DNS benchmark. I does happen when not benchmarking of course. It happens the same on two, distinct, fresh installed and perfectly working Ubuntu 14.04 LTS install.

I've researched the web, found a few hints ( related to dnsmasq / new Ubuntu way to handle DNS requests / local nameserver ), but nothing that allowed me to get rid of those ennoying DNS replies drop.

Any clues about this ?

  • do you have a NAT router between you and the openDNS servers? NAT has some trouble with UDP protocols because it can't use syn values to indicate the L4 connection the datagram is part of. Instead they tend to monitor outgoing requests, and set a timer that allows udp flows from the destination observed back to the port specified only until the timer expires. Usually I've had to configure my firewall to allow UDP\53 to udp\53 from my Bind instance to the known list of DNS servers I use. Dec 3, 2014 at 14:49
  • I don't think it's a NAT-related issue : First, IPv6 is affected as well. Secondly, my Debian computers don't show this eerie 'dropped DNS replies' habbit. My guess is that it looks Ubuntu-related ...
    – networkIT
    Dec 5, 2014 at 8:54

2 Answers 2


This can happen when a response comes in very late from an outside nameserver for a query that was sent from some process on your machine after the process has given up and exited. This closes the sockets and frees up the ephemeral port the DNS resolver was using to wait for the reply. This is not uncommon, but should happen infrequently as you are seeing.


Sometime dnsmasq queries all its name servers in parallel. It does this when it first starts and if there hasn't been traffic for a while, to see which name server is best to use. Under load it does this rarely. Whenever dnsmasq does a parallel query, the second reply (if any) will reach a closed port, thus creating the ICMP unreachable port message.

More info can be found at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580064.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.