uTorrent causes DNS to stop working occasionally

While using uTorrent, DNS periodically stops responding.

The problem appears to not be related to too much bandwidth usage (as seen from the router to the computer), but may be related to some form of flood-protection provided by the router (more incoming connections to router than Windows will accept).

How do I get the network to work properly (while still being able to use uTorrent, of course)?

bittorent clients aggressively connect to peers ... and some routers interpret this as a syn-flood.

Open Connections

When uTorrent is loaded and uploads/downloads are paused (not stopped) it maintains open connections with your peers. Meanwhile legions of internet peers will still attempt to connect to you to find out if you have the bits they want.

Eventually you will reach the open connection limit imposed by your OS (in Windows 7 this is 10 connections) and connections from new clients will start queuing at your router.

Queued clients will check aggressively to see if a connection is free. This aggressive polling may be interpreted as a syn-flood attack by the router.

Solutions

• lower your half-open connection limit in your bittorent software below the connection limit imposed by your OS
• disable IP flood protection at your router/modem.

Bandwidth Saturation

In addition, with uTorrent (or any bulk traffic) connection running unrestricted, the upload (and possibly download) pipe reaches full usage, forcing some "upkeep" traffic to take a back seat, which ends up decreasing network usefulness.

Here is an example:

1. High speed download (torrent or otherwise) saturates downstream link.
2. User tries to browse to a site not recently visited. Computer generates a request for DNS info for desired site. "Upload" of request to DNS server succeeds (not challenged for upstream pipe access).
3. DNS server responds (or tries to), but response gets hung up on trying to get to the user's machine because the download pipe is saturated with download content, and since something has to be dropped, and the download is aggressive about maintaining speed, the DNS response gets dropped (at some point before it gets to the local router).

The same thing can happen if upload is unrestricted. With upload saturated, packets known as TCP-ACK (which are sent as "Hey, I got packet xyz successfully" type responses) get hung up, making downloads grind to a halt, causing web browsing to become very patchy.

Solutions

• Figure out what the maximum capabilities of your connection are (up and down, individually), and set the maximum speed of your bulk transfer clients to not use more than about 80% of that speed. This will leave "headroom" for things like DNS and TCP-ACK packets to bypass the bulk traffic and get dealt with quickly.
• Use a router that can handle traffic shaping such that certain traffic (DNS, IMCP Ping, TCP-ACK) can be prioritized ahead of other forms of traffic, and some forms of traffic (torrent in particular) can be de-prioritized. This is my preferred method. This can give the added benefit of allowing the full up and down pipe to be usable for torrent traffic when higher priority traffic does not challenge it.
• Use some combination of 1 and 2 to restrain "misbehaving" traffic.

If interested in more info about traffic shaping Linux/BSD distros, MonoWall and IPCop both have some good information.

When I have something like that, Wireshark is my best friend.

But first it's good to realize these three things:

• The fact that ping is working does not mean that the DNS (or any other service) is working, and Vice-versa.

  That is because ping uses completely different protocol (ICMP, while DNS uses IP and a combination of UDP and TCP), on a completely different level of network model. Anything on the way, from your personal firewall through the number of routers to the actual host where the service is running can potentially be configured to throw away one of these but not the other (whether it be admin's paranoia or some failure case), although it normally rather happens to ICMP than others

• Generally, it's also good to make clear whether it's your (DNS) requests or the replies that are getting lost.

  Well, the particular program you are using should make this clear for you but as a general rule, it's easier to see it yourself in the Wireshark GUI :)

• As I have mentioned, DNS normally uses UDP as way to deliver the contents of request and response.

  In contrast of it's brother TCP, UDP is defined in a way that there is no guarrantee that the packet will be delivered at all, and there is nothing a router must (nor can) do to let you know about failure. (This is a sacrifice for the another feature of UDP: it's incredibly fast. Routers do not have to keep any information about sender nor order of packets, they just rapidly pass it on and forget. They can even quite safely give them higher priority than TCP.)

Usually first thing I'd do would be:

1. Start Wireshark
2. Click Capture Options
3. For Capture filter, set host 1.2.3.4 to make sure you are only capturing traffic between you and 1.2.3.4
4. Start capture
5. Once you have all fired up this way try your commands

However, based on your last update: I don't know this piece of software, but I'd definitely suspect the uTorrent client. It's possible for an application to send too many UDP that e.g. some limit is reached on your home router and it starts to throw UDP packets away.

I would try the DNS Benchmark tool from GRC. It tests the DNS servers that you're configured to use, as well as a lot of other DNS servers. Not only does it test their speed, but also their reliability. It's free and doesn't need to be installed (it is Windows only though). There's also a lot of good information about DNS on those pages too.

I would like to know in which part of the world you are situated, and it would help to have a tracert/traceroute result for google.com and for 8.8.8.8.

The problem could possible be caused by either your router or by your connection to Google's servers. The intermittent nature of your problem has the smell of bad connectivity, but there are simply too many factors when analyzing Internet connectivity problems to give you a straightaway answer.

Google's network can occasionally become over-burdened. I have daily cases where a request to google.com times out and needs to be restarted, and I do use its local server for my country. It's partly a matter of luck to which segment of Google's network the request is routed, and there may even be inefficiencies in Google's internal request-distribution algorithms.

It is probably the same way with Google's name-servers. Although Google has several of them, the request may be routed to a momentarily over-burdened internal server or network segment.

You have not mentioned in which part of the world you are situated. If you are not in the US, then each request may take a different route and may experience occasional problems or delays if dependent upon too many intermediate servers.

Not to mention any "optimizations" or possible deficiencies of your ISP, or any optimizations that Google may have done to partition the burden world-wide on its servers.

Using a far DNS server may penalize you in other ways. See :

Why using Google DNS / OpenDNS is a bad idea
Should I use my ISP's DNS, or Google's 8.8.8.8?

I found solution, although I don't fully understand it, if anyone can explain it properly please post it as answer and I will give bounty to him, because other answers didn't help.

As I mentioned in question's appendix, uTorrent was related to problem, because closing uTorrent solved the problem. I decided to find out how to fix it without need of closing uTorrent. In this thread and this one (it was very relevant because people there have the same ISP and router) I found suggestions that I should disable IP flood protection on my router and it did the trick! The problem and solution were exotic, possibly specific to router Cisco EPC3925 or even to particular ISP (popular in Europe, that's why it was hard to google something in English).