Carlos E. R. wrote:
And how many other services do you run UDP with -- which is likely the default for lower-powered routers doing DNS resolution? None to the outside, as far as I know. Or next to none.
That was my point. If the router is using udp queries and if a download stream runs, TCP's "ACK"s are more likely to be prioritized than than UDP -- thus the problem.
I found out how to do "bandwidth control" on my router, it does not have QoS. It is not clearly explained on the manual, which just about prints nice photos of the screen, with empty boxes so that I can not guess what is the acceptable syntax (it is a TP-Link TD-W8970)
Description Priority Upstream Bandwidth Downstream Bandwidth Status Min Max Min Max 192.168.1.2-192.168.1.254 /53 /ALL 5 1 100 1 100 Enable =====
??? Description??? That doesn't sound like a place one puts addresses. Does it want destination IP's or source IP's? Description doesn't really tell you. It certainly doesn't specify if the policy is for TCP, UDP or ICMP (for example).
which reads, I understand, like all internal machines (it does not allow external IPs defined in there) on port 53 UDP and TCP have a minimum of 1Kb/s reserved. For that port, I assume. It appears to work better, housewide.
I had to google many forum pages from people asking how to do it. Some answers just said to flash the device, which is not an answer.
---- If you say so... I've zero knowledge about how to config your router (not even knowing the brand/make/model...etc.).
No, it doesn't for multiple reasons (any *1* of which could cause problems as you are seeing).
1) your pc dns queries to a recursive resolver, are likely TCP, so they won't time out and will have reliable connections while the recursive resolver does any needed resolution.
But you see, I'm using my PC DNS daemon, aka bind. And it times out.
Doesn't matter. Your PC DNS daemon likely uses TCP to talk to the router, and the router likely uses UDP to talk upstream. If you config your PC DNS daemon to another DNS server, it may easily be TCP all the way.
You see, it first has to get a connection on port 53 to somewhere established... if this can not be made, it does not matter that once done it times out or not.
"It" = PC or router? Connect -- UDP = connectionless.
5) if you are querying your ISP (or google) they likely have the answer to your query in their cache meaning they have no lookups to do and you just need to get a reply.
Which I don't get.
And some of the queries are to my isp asking for my isp smtp server, and they time out.
---- But are you doing those queries through your router? If it uses UDP, it would do so to your ISP as well. If the problem is UDP is being short-shrifted, due to TCP buffer filling, then you'd expect no resolutions to work. If you have your DNS server set to be your ISP or google, then it likely uses TCP that could avoid the problem. One thing we don't know .. the types of the queries.. It would be good to use wireshark and look at the queries from your box to both, the router and to another DNS server. AND 2) hook a 2nd ethernet port up on the outside of your router and look how it is sending out the queries -- using TCP or UDP.
But my PC, which queried my router, does have the cache. It is not powered off, but hibernated, so it should keep. And it doesn't.
And in fact... look: .... That makes me think part of your problem is that the router is lying to you. If it isn't your router, don't expect the truth.
Look .. at this output from a dig command on my system: It looks like it is mostly cached:
dig smtp.telefonica.net
; <<>> DiG 9.9.2-P2 <<>> smtp.telefonica.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54048 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;smtp.telefonica.net. IN A ;; ANSWER SECTION: smtp.telefonica.net. 300 IN A 86.109.99.70 ;; AUTHORITY SECTION: telefonica.net. 167431 IN NS marianela.tsm.es. telefonica.net. 167431 IN NS artemis.ttd.net. ;; ADDITIONAL SECTION: artemis.ttd.net. 167431 IN A 213.0.184.69 marianela.tsm.es. 129854 IN A 194.224.100.67 ;; Query time: 549 msec ;; SERVER: 192.168.4.1#53(192.168.4.1) ;; WHEN: Mon Jul 14 19:08:11 2014 ;; MSG SIZE rcvd: 152 === That says the telefonica.net servers have a 40+ hour lifetime. The root name servers would NOT have your address in their DB -- it appears from YOUR lookup output, that you are using the root name servers to do recursive lookups. If you think doing root lookups of the TLD's is rude, how do you see those who ask the root nameservers to do the lookup for them? *ahem*.. Here is what the same resolution with +trace (cache is off, recursion is off):
dig +trace smtp.telefonica.net
; <<>> DiG 9.9.2-P2 <<>> +trace smtp.telefonica.net ;; global options: +cmd . 423888 IN NS m.root-servers.net. . 423888 IN NS c.root-servers.net. . 423888 IN NS i.root-servers.net. . 423888 IN NS j.root-servers.net. . 423888 IN NS b.root-servers.net. . 423888 IN NS k.root-servers.net. . 423888 IN NS f.root-servers.net. . 423888 IN NS a.root-servers.net. . 423888 IN NS e.root-servers.net. . 423888 IN NS h.root-servers.net. . 423888 IN NS g.root-servers.net. . 423888 IN NS d.root-servers.net. . 423888 IN NS l.root-servers.net. . 474832 IN RRSIG NS 8 0 518400 20140721000000 20140713230000 8230 . YPoOPm1bPqWYUhGtXc/yTFy1wlRspvqqVIK8hpBG6VZ6qldXXtfxQc0D Xs0IIYyexHZiwoH+8cE2N3lKpovTGBGQ4r2EOdL80VGS9Fj6DGdlW2ea doWFmBN44BywqkMdlnKB1m+POBTywqwbuAFOSDc3MJEMGjlfxRsCZVz9 wxw= ;; Received 913 bytes from 192.168.4.1#53(192.168.4.1) in 12 ms net. 172800 IN NS a.gtld-servers.net. net. 172800 IN NS b.gtld-servers.net. net. 172800 IN NS c.gtld-servers.net. net. 172800 IN NS d.gtld-servers.net. net. 172800 IN NS e.gtld-servers.net. net. 172800 IN NS f.gtld-servers.net. net. 172800 IN NS g.gtld-servers.net. net. 172800 IN NS h.gtld-servers.net. net. 172800 IN NS i.gtld-servers.net. net. 172800 IN NS j.gtld-servers.net. net. 172800 IN NS k.gtld-servers.net. net. 172800 IN NS l.gtld-servers.net. net. 172800 IN NS m.gtld-servers.net. net. 86400 IN DS 35886 8 2 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE net. 86400 IN RRSIG DS 8 1 86400 20140721000000 20140713230000 8230 . hldv3ZmwyI9DRXgT5nLrpUWdWo7GBj0mDuzOGjeI6nvkFyipte81unBs WjzcGg8HYe3bWqoxLlSYYrDuLC6iF1TAZO0x67KTLIRyWXnQfJ3mZ23B ofPCDvbUzfAfJSPD+7AlfXewuPSFTd3PkWrprdJsx/jzp3Xk2pO5UNh6 smI= ;; Received 740 bytes from 128.63.2.53#53(128.63.2.53) in 2194 ms telefonica.net. 172800 IN NS artemis.ttd.net. telefonica.net. 172800 IN NS marianela.tsm.es. A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. 86400 IN NSEC3 1 1 0 - A1RUUFFJKCT2Q54P78F8EJGJ8JBK7I8B NS SOA RRSIG DNSKEY NSEC3PARAM A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. 86400 IN RRSIG NSEC3 8 2 86400 20140720045242 20140713034242 28829 net. ofaElVWkIRiDy4pig1jkaDSzPquUyCa4r42dyX/4XS9Iat+Yq2Dj/ZnB JDPPzML9nyrvUNEVnGNlMH9gTIjcI0S+8uswp2JYkSj0Ehy2lBD8l4ih rC50D6ipg5EjamyC+CwY2PfFbwWF3oU9LLoo2ETGVDhD7JQ9/fH7hbNT 0Ms= AS5B4OTLCDJL1A0LTE25I08AP8R6R3GM.net. 86400 IN NSEC3 1 1 0 - AS637D1KGJ6QJLHQN5SR8DM905KVGFG9 NS DS RRSIG AS5B4OTLCDJL1A0LTE25I08AP8R6R3GM.net. 86400 IN RRSIG NSEC3 8 2 86400 20140721045414 20140714034414 28829 net. dJjhB9d0dnxHccfe/WeTAnt46aWqoOgLPREUWyWK2f5ExoZye7EfhPKt O/XMBS2OdA7R3Hq2vNFsqqLYI/5DdPZ+r/Q4q7Z6//KCq3tx6Q5FHagd Hg1yDgFCWg9kUXqQCqk/6dEvEGxCz6IIYCPlK05iUVUPt8jEI0KlodPI e7Q= ;; Received 605 bytes from 192.54.112.30#53(192.54.112.30) in 1176 ms smtp.telefonica.net. 300 IN A 86.109.99.70 telefonica.net. 300 IN NS marianela.tsm.es. telefonica.net. 300 IN NS artemis.ttd.net. ;; Received 152 bytes from 213.0.184.69#53(213.0.184.69) in 596 ms But by default, if you ask for the root-namespace (which I do once a week, script attached), you get back:
dig +nocomments +noquestion +norecurse @a.root-servers.net . NS 2>root.err >root.new more root.new
; <<>> DiG 9.9.2-P2 <<>> +nocomments +noquestion +norecurse @a.root-servers.net . NS ; (1 server found) ;; global options: +cmd . 518400 IN NS c.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS d.root-servers.net. c.root-servers.net. 3600000 IN A 192.33.4.12 c.root-servers.net. 3600000 IN AAAA 2001:500:2::c a.root-servers.net. 3600000 IN A 198.41.0.4 a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 3600000 IN A 192.228.79.201 b.root-servers.net. 3600000 IN AAAA 2001:500:84::b m.root-servers.net. 3600000 IN A 202.12.27.33 m.root-servers.net. 3600000 IN AAAA 2001:dc3::35 h.root-servers.net. 3600000 IN A 128.63.2.53 h.root-servers.net. 3600000 IN AAAA 2001:500:1::803f:235 l.root-servers.net. 3600000 IN A 199.7.83.42 l.root-servers.net. 3600000 IN AAAA 2001:500:3::42 j.root-servers.net. 3600000 IN A 192.58.128.30 j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30 i.root-servers.net. 3600000 IN A 192.36.148.17 i.root-servers.net. 3600000 IN AAAA 2001:7fe::53 g.root-servers.net. 3600000 IN A 192.112.36.4 k.root-servers.net. 3600000 IN A 193.0.14.129 k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 e.root-servers.net. 3600000 IN A 192.203.230.10 f.root-servers.net. 3600000 IN A 192.5.5.241 f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f d.root-servers.net. 3600000 IN A 199.7.91.13 d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d ;; Query time: 389 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Mon Jul 14 19:20:37 2014 ;; MSG SIZE rcvd: 755
Despite me having on /etc/named.conf
forwarders { 80.58.61.250; 80.58.61.254; 208.67.222.222; 8.8.8.8; }; forward first;
it is asking the root servers.
---- What is in /etc/resolve.conf? I'm fairly sure it is consulted first, as it contains the values of the nameservers.
I know they are different; but the current problem, which is simply getting queries done, is basically the same: the router performance when the ADSL pipe is full.
---- Your router has to control the traffic.... it sounds like it doesn't. Some client (like your PC) is taking all the BW. There is no BW control. Um... that looks problematic. #!/bin/bash -ue cd /etc/named.d || { echo "dying, could not cd to /etc/named.d"; exit -1 ; } bc=$(wc -m root.db) bc=${bc%% *} bl=$(wc -l root.db) bl=${bl%% *} if [[ -e root.new ]]; then chkmsg="$(ci -d -l -m\"\" -M -T -wlaw -t-"" -zLT root.db)" mv root.new root.db ( echo -i "Installed yesturday's root.new as the current db before getting the new root.db hintfile. If you want to retrieve the old root.db, it it was stored in RCS as $chkmsg Continuing...") | Mail -s "FYI - installed yesterday's new named.db file" law fi dig +nocomments +noquestion +norecurse @a.root-servers.net . NS 2>root.err >root.new if [[ ! -s root.new ]] ; then (echo "Error getting new root.new file. Any messages follow:" cat root.new root.err ) rm -f root.new root.err exit -1 fi ac=$(wc -m root.new) ac=${ac%% *} al=$(wc -l root.new) al=${al%% *} if (( $ac<9*$bc/10 || $al<9*$bl/10 )); then ( echo -e "Diff -y Current | New:\n------" echo -e "-------\nIf you do nothing, it will be installed tomorrow before just before next fetch." ) | \ Mail law -s "Check new /etc/named/root.new hint file. It's less than 90% of old." else ci -d -l -m\"\" -M -T -wlaw -t-"" -zLT root.db mv root.new root.db rm -f root.err fi