no internet while downloading torrents - seems dns related
(Shouldn't the kernel be divide time among processes that request to send/receive packages?)
The typical situation with having slow or no Internet with something like Bittorrent saturating your connection is that incoming traffic on your upstream (which is usually lower than your downstream on most residential connections) is crowded out. So incoming TCP ACKs are not received timely, and connections timeout on their end, and then eventually your end.
One thing I learned from studying QoS is that there is no such thing as QoS on incoming traffic, because you can't control what's being sent to you. You can only really QoS/divide/share outgoing traffic. You can see the current Linux QoS configuration with tc
- but be warned, tc
is very complicated.
It's possible that a single connection could saturate your incoming bandwidth and crowd out incoming TCP ACKs, causing slowdowns, drops, etc. The number of concurrent connections doesn't really matter.
You probably need to set the total amount of bandwidth your Bittorrent program uploads to just under your maximum upstream, like 8Kbit/sec below what you know is the speed of your upstream. You also might want to look into Wondershaper if you feel like going down the rabbit hole that is QoS on Linux.
Your clue is this line:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26154
Assuming that resolv.conf
only contains 127.0.0.1
, this tells you that you that the caching server has decided that the upstream nameservers cannot be reached or is misconfigured. At that point, the server is going to give up on communicating with that domain. This means that the server is added to the list of lame nameservers. This is different from negative caching, which only applies to NXDOMAIN
responses.
It stands to reason that once facebook.com
has been determined to be dead, that the caching nameserver isn't going to bother trying to resolve it for awhile. You now have to figure out why that's happening.
Let's assume that you're experiencing network congestion, and facebook.com
is not in cache.
-
named
is going to try to cycle through your list of forwarders until it finds a nameserver that will respond with anything other thanREFUSED
for that record.NXDOMAIN
andSERVFAIL
responses that it will accept. Even if the other servers would have answered differently, all your server cares about is whether or not a record is in cache, and the first valid response that it gets. - Once it finds an answer, that will be cached. For better or worse.
- Failure to get an answer from any of them will be considered a
SERVFAIL
as well.
For your particular test, the query and response would be small. UDP doesn't have the session overhead associated with TCP. To get a response of SERVFAIL
...
- The first valid reply you received was
SERVFAIL
for that domain. - All of the forwarders were unreachable. You failed to get a response from all of them.
The only way to know what's going on for sure would be to start a packet capture, then restart your nameserver and analyze the packets. One of your forwarders may be bad and returning SERVFAIL
frequently, or your congestion is so potent that eight tiny DNS lookups against your entire forwarder list fail.