[opensuse] When I have downloads running, DNS fails.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have a nuisance problem. When I have dowloads running, using my full internet pipe, which is just 1 mbit/s ADSL via dedicated router, DNS queries fail, meaning that anything internet related fails, in the entire house. It does not matter what machine is doing the download. (I can do several downloads at the same time, though) Aparently, the router is not capable of prioritizing and doing two things at the same time, like doing a download, and querying upstream DNSs. What would be the best strategy to at least paliate this? At this moment, this machine is using bind, with this config: forwarders { 192.168.1.1; }; forward first; which means that it asks my router, which in turn asks my ISP. Maybe I should tell my machine to query some other DNS server outside, instead, in case it is just the router which can not do two things, but it may allow packages to go in or out... :-? - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO+vucACgkQtTMYHG2NR9UZGQCdFuztYdNraGwxK7lfFd1g7it/ hcwAn2CFdqbEf6gFRlgAGd3CcjNmpcDv =kUSU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/07/14 13:27, Carlos E. R. wrote:
Hi,
I have a nuisance problem.
When I have dowloads running,... , DNS queries fail, [snip]
At this moment, this machine is using bind, with this config:
forwarders { 192.168.1.1; }; forward first;
which means that it asks my router, which in turn asks my ISP. Maybe I should tell my machine to query some other DNS server outside, instead, in case it is just the router which can not do two things, but it may allow packages to go in or out... :-?
-- Cheers Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)
To determine if it is the router, try pinging it before and while you are downloading. If the delay goes up whilst downloading, then it could very well be your router. If it is relatively the unchanged, then it could be your bandwidth is too congested for your 1 Mbit connection. Perhaps there is a way to increase the timeout for the DNS response on the router or on your machine? It will depend on if the DNS request times out on the router or on your machine. Another option is looking into your router's settings and see if you can use QoS and put DNS has a high priority? Cheers, Alvin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 10 of July 2014 18:27:19 Carlos E. R. wrote:
Hi,
Hi,
When I have dowloads running, using my full internet pipe, which is just 1 mbit/s ADSL via dedicated router, DNS queries fail, meaning that anything internet related fails, in the entire house. It does not matter what machine is doing the download.
Aparently, the router is not capable of prioritizing and doing two things at the same time, like doing a download, and querying upstream DNSs.
You're lucky. My router simply ignores DNS requests even though it is configured as a DNS server by the ISP...
What would be the best strategy to at least paliate this? Maybe I should tell my machine to query some other DNS server outside, instead, in case it is just the router which can not do two things, but it may allow packages to go in or out... :-?
There was a script some years ago that configured the IP stack for traffic shaping, named wondershaper or something like that, that would reduce the throughput when sending and set traffic priority accordingly, so that the router does not choke and delay low-latency traffic, such as the DNS requests. There's also shorewall, which allows you to configure QoS in many aspects, but I don't know how much effect this may have if the router does not support QoS. Essentially, you'll have to configure traffic priority on another computer and maintain low enough throughput, so that the router simply forwards all the packets it receives without queuing them. Of course, you could also configure the programs that upload data not to saturate the bandwidth, if possible at all. -- Regards, Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
auxsvr@gmail.com wrote:
There was a script some years ago that configured the IP stack for traffic shaping, named wondershaper or something like that, that would reduce the throughput when sending and set traffic priority accordingly, so that the router does not choke and delay low-latency traffic, such as the DNS requests.
wondershaper works quite well, but it's a big/difficult gun and I don't think bandwidth for DNS requests is really the issue.
There's also shorewall, which allows you to configure QoS in many aspects, but I don't know how much effect this may have if the router does not support QoS.
More importantly, if it is indeed a bandwidth issue, the rest of the uplink would have to adhere to QoS too.
Of course, you could also configure the programs that upload data not to saturate the bandwidth, if possible at all.
I do that frequently when I transfer recorded video between my two mythtv backends - if I leave rsync to go at full speed, it impacts watching TV at the same time, so I usually use the --bwlimit option, it works really well in that situation. -- Per Jessen, Zürich (11.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2014-07-10 at 19:26 +0200, Per Jessen wrote:
Of course, you could also configure the programs that upload data not to saturate the bandwidth, if possible at all.
I do that frequently when I transfer recorded video between my two mythtv backends - if I leave rsync to go at full speed, it impacts watching TV at the same time, so I usually use the --bwlimit option, it works really well in that situation.
I was considering of using trickle with yast and firefox... but now it works by not quering the router DNS, so I'l delay that idea :-) - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO/JOQACgkQtTMYHG2NR9VPAgCfX3aYzpPDkAUAsi+innsROzki P1MAoIvviRQCV6IoBTt8/gjlSwTzEEaL =rW+c -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Thu, 10 Jul 2014 19:26:09 +0200 Per Jessen <per@computer.org> пишет:
auxsvr@gmail.com wrote:
There was a script some years ago that configured the IP stack for traffic shaping, named wondershaper or something like that, that would reduce the throughput when sending and set traffic priority accordingly, so that the router does not choke and delay low-latency traffic, such as the DNS requests.
wondershaper works quite well, but it's a big/difficult gun and I don't think bandwidth for DNS requests is really the issue.
The problem is not bandwidth, but queue size and associated latency. PC on LAN sends data with 100Mb/s which results in relatively huge amount of data buffered in router which can only send with 1Mb/s. The solution is indeed to use traffic shaping to restrict bandwidth on a system to 1Mb/s. This won't affect throughput (you cannot transfer more than that anyway) but will minimize latency. I have started with 128Kb/s ADSL so I went through it ...
There's also shorewall, which allows you to configure QoS in many aspects, but I don't know how much effect this may have if the router does not support QoS.
More importantly, if it is indeed a bandwidth issue, the rest of the uplink would have to adhere to QoS too.
Of course, you could also configure the programs that upload data not to saturate the bandwidth, if possible at all.
I do that frequently when I transfer recorded video between my two mythtv backends - if I leave rsync to go at full speed, it impacts watching TV at the same time, so I usually use the --bwlimit option, it works really well in that situation.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-11 04:37, Andrey Borzenkov wrote:
В Thu, 10 Jul 2014 19:26:09 +0200 Per Jessen <> пишет:
The problem is not bandwidth, but queue size and associated latency. PC on LAN sends data with 100Mb/s which results in relatively huge amount of data buffered in router which can only send with 1Mb/s.
But I was not sending: I was downloading. Four simultaneous yast update sessions, in fact. The upload rate should be very small, as about only the acknowledgments of the packages received were sent, and other negotiations or whatever they are called. The problem, as I said on other posts, turned to be not Internet pipe saturation, but that the DNS server or relay on the router can't cope, while a bind daemon on my computer, using the same router and pipe, copes fine. Well, not exactly fine, a bit slow, but it responds. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2014-07-10 at 20:07 +0300, auxsvr@gmail.com wrote:
On Thursday 10 of July 2014 18:27:19 Carlos E. R. wrote:
When I have dowloads running, using my full internet pipe, which is just 1 mbit/s ADSL via dedicated router, DNS queries fail, meaning that anything internet related fails, in the entire house. It does not matter what machine is doing the download.
Aparently, the router is not capable of prioritizing and doing two things at the same time, like doing a download, and querying upstream DNSs.
You're lucky. My router simply ignores DNS requests even though it is configured as a DNS server by the ISP...
These things are cheap, and they cut corners somewhere. My previous one failed completely with some wireless devices, but did not have this particular problem.
What would be the best strategy to at least paliate this? Maybe I should tell my machine to query some other DNS server outside, instead, in case it is just the router which can not do two things, but it may allow packages to go in or out... :-?
There was a script some years ago that configured the IP stack for traffic shaping, named wondershaper or something like that, that would reduce the throughput when sending and set traffic priority accordingly, so that the router does not choke and delay low-latency traffic, such as the DNS requests.
Ah, but what is maxed is my download pipe, not the upload. I should be able to send the DNS request, but I do not get the answer, aparently. But I'm unsure about this, because I have tried with several simultaneous downloads and they keep working, without missing a packet, apparently... So it could just be that the router itself is too busy to give cpu cycles to its DNS daemon. I will try to bypass it.
Of course, you could also configure the programs that upload data not to saturate the bandwidth, if possible at all.
But it is the download rate which saturates. And many programs, like yast or firefox, do not have that feature: I have to use them via trickle. And if the downloads come from different machines, forget it. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO+4GQACgkQtTMYHG2NR9UbwgCeLW7F5CSKqOR0PXGJ0+L8bl15 CcYAn3hr8Lr7/2jfUEmOJogaG1zGXCxk =Ll7J -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Have you looked at the package 'qos'-1.0.1 Rel 2.1.2 in opensuse 13.1? (> rpm -qf /etc/rc.d/qos qos-1.0.1-2.1.2.noarch) It uses filters in both directions to help prioritize. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-11 04:10, Linda Walsh wrote:
Have you looked at the package 'qos'-1.0.1 Rel 2.1.2 in opensuse 13.1? (> rpm -qf /etc/rc.d/qos qos-1.0.1-2.1.2.noarch)
It uses filters in both directions to help prioritize.
In this particular case, that alone would not help. I was querying my router for DNS service, and it is this one which failed. The pipe to the router was not a problem. I just told my named/bind to query instead my ISP DNS servers, and it works - using the same pipe. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-07-11 04:10, Linda Walsh wrote:
Have you looked at the package 'qos'-1.0.1 Rel 2.1.2 in opensuse 13.1? (> rpm -qf /etc/rc.d/qos qos-1.0.1-2.1.2.noarch)
It uses filters in both directions to help prioritize.
In this particular case, that alone would not help.
I was querying my router for DNS service, and it is this one which failed. The pipe to the router was not a problem.
I just told my named/bind to query instead my ISP DNS servers, and it works - using the same pipe.
---- Your router for DNS? How odd. I've never heard of having a linux box, then using a small underpowered microprocessor to do DNS.... Um... why are you using a router? My linux box does my routing and DNS (and a score or two of other things). I.e. your linux box has to do queries to resolve DNS. If it does so from the root, then it has to send out ... 1 request to a root server to see who owns the TLC, then to the TLC to see who owns the domain... then to the domain to see what the ip of it's servers is... That's about 3 requests minimum (assuming a cold cache)... The thing is, a small solid-state router won't have alot of cache memory to hold many entries. You are talking to a server that likely only has to make 1 trip-- google I read? They likely have the root and TLC's at least in their cache all the time, as well as the website addrs of all the major sites. I.e. likely to be at most 1 round trip from them -- but more likely, *0* roundtrips. All that is needed is for them to satisfy your request from cache. So color me unconvinced.. but having your lower powered router look up a DNS addr, is alot more likely to run into traffic contention problems given the round trips to all the authoritative servers for each level. Google will just hand you a cached value... and have paid for a ton of Band/wth -- unlike the traffic between you and each DNS host. Someone else pointed out that if udp is too slow, it would fall back to TCP. But thing is -- when you point at google there's a reasonable chance it would be TCP from the start, coming from your computer... but the tiny-router box -- it would more likely use UDP because of its lower overhead. So you can't really compare the two and claim that lack of B/W, up or down, (both need to be available) or "being busy" isn't the problem. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-11 07:56, Linda Walsh wrote:
Carlos E. R. wrote:
Your router for DNS? How odd. I've never heard of having a linux box, then using a small underpowered microprocessor to do DNS....
Home routers are typically running Linux or a variant, and all the home routers I tried have what /they/ /call/ a dns service, which can be just a re-sender to the DNS addresses negotiated with the ISP. It makes things easy, while using dhcp for some devices, to get a DNS server for the entire home network, guaranteed to be alive. Not all my home devices can configure a DNS service at all, in their local network configuration. For instance, on my ebook I can't, so the mandatory DHCP service has to supply one. And on those machines, like computers, where you really can configure the network, it is easier to tell them to ask the router address for DNS queries, which typically works with my laptop even when moving from place to place. The alternative is to configure them with the DNS address of my provider (I prefer not to use google's if I can avoid it). But my provider do not publish them, and they can change. And my laptop can be connected to different providers. So telling all those machines to use the local router for that service is simply one complication less to think about.
Um... why are you using a router? My linux box does my routing and DNS (and a score or two of other things). I.e. your linux box has to do queries to resolve DNS.
Because it is there, full time. I need "something" to connect to my ISP ADSL, however you call that box, and an ADSL router does just that out of the box. So I have a small box, that connects to the phone line, that has wifi, does dhcp, does dns (but faulty in this particular model), does a few other things, and uses very little electricity, which is important for me. Yes, I know that a small computer can do way more. But, I would need "something" to connect to the ADSL, then a linux box with two eth ports, and a wifi access point, then a switch. That's a total of three boxes minimum, all draining power and using space, and possibly administration time. I don't have a suitable machine for that task, besides the existing router. So I don't see a justification for the hassle. If I were setting up a larger local network, then certainly I would. And more things, like proxy, firewall, etc.
If it does so from the root, then it has to send out ... 1 request to a root server to see who owns the TLC, then to the TLC to see who owns the domain... then to the domain to see what the ip of it's servers is...
I consider asking the root servers myself "not polite".
That's about 3 requests minimum (assuming a cold cache)...
The thing is, a small solid-state router won't have alot of cache memory to hold many entries. You are talking to a server that likely only has to
For that reason I run bind cache on my computer ;-) I have done that since about 1999.
So color me unconvinced.. but having your lower powered router look up a DNS addr, is alot more likely to run into traffic contention problems given the round trips to all the authoritative servers for each level.
My previous router, which was a cheap model supplied by the ISP, did this DNS service just fine. It was not a problem. Other routers I have used do it fine. It is just this particular brand and model which fails. In fact, it is the first time I see this particular issue. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
I consider asking the root servers myself "not polite".
Well unless you speak named protocol, you'd be wasting their time. I usually let named talk to them directly. How else do you do a domain lookup? You indicated some concern over having all your DNS entries forwarded to someone else for resolution, but if you rely on someone else looking up things for you, that's exactly what you are doing -- forwarding all your DNS entries to someone else to resolve for you...
For that reason I run bind cache on my computer ;-) I have done that since about 1999.
---- Ahh.. but we are discussing the case where the DNS lookups are not in an intermediate cache... ;-)
So color me unconvinced.. but having your lower powered router look up a DNS addr, is alot more likely to run into traffic contention problems given the round trips to all the authoritative servers for each level.
My previous router, which was a cheap model supplied by the ISP, did this DNS service just fine. It was not a problem. Other routers I have used do it fine. It is just this particular brand and model which fails. In fact, it is the first time I see this particular issue.
---- Are you comparing apples w/apples? I.e are your different lines the same speed and capacity?? Are your computers the same now as then? Or would they be able to ask for traffic more quickly and possibly saturate your local line to the exclusion of other traffic (like DNS)? Generally, the trend has been toward higher usage, which can easily translate to congestion or lower performance -- especially if you have some high-bw progs saturating your line. As someone else mentioned, your newer model router might have bigger io-buffers, and might give better download performance, but worse interactive performance during a download. Until your DNS traffic is prioritized above the "ACK"s on download streams, which many home routers have implemented to improve throughput, high download saturation may slow down DNS communication -- especially where the resolution is done on your end (vs. always using someone else's DNS server, maybe your ISP's or google's). The ACKS from the DNS traffic have to compete with your download traffic, and unless you use ingress filtering, DNS could become unresponsive due to the download. This effect can be worsened by DNS's defaulting to UDP as it doesn't have tcp's auto-correction mechanisms. also, on QOS, everything else doesn't need to set QOS. Only the traffic you want to prioritize. Traffic w/o the QOS settings is placed in "the bulk" is given "normal" "best-effort" -- so it can speed up some traffic by prioritizing some traffic over 'bulk' (unrated). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-11 16:09, Linda Walsh wrote:
Carlos E. R. wrote:
I consider asking the root servers myself "not polite".
Well unless you speak named protocol, you'd be wasting their time. I usually let named talk to them directly.
I don't.
How else do you do a domain lookup?
By asking the DNS server of my ISP, which will respond directly if it has the answer, or query the root servers for me. This diminishes the load on the root servers, and is considered the polite behaviour. Everybody on a particular ISP asks that DNS server, concentrating the load on it, not on the root servers. A domain, in this context, is opensuse.org, or google.com.
You indicated some concern over having all your DNS entries forwarded to someone else for resolution, but if you rely on someone else looking up things for you, that's exactly what you are doing -- forwarding all your DNS entries to someone else to resolve for you...
No. I expressed concern on handling my queries to google, specifically, because it does data mining on them. My ISP, as far as I know, does not.
For that reason I run bind cache on my computer ;-) I have done that since about 1999.
---- Ahh.. but we are discussing the case where the DNS lookups are not in an intermediate cache... ;-)
All my queries are cached by bind or dnsmasq on their respective computer. But those entries time out eventually and they are deleted, so that when needed again the local cache dns server has to ask outside, again. They are, and they were. For many years.
My previous router, which was a cheap model supplied by the ISP, did this DNS service just fine. It was not a problem. Other routers I have used do it fine. It is just this particular brand and model which fails. In fact, it is the first time I see this particular issue.
---- Are you comparing apples w/apples?
I.e are your different lines the same speed and capacity??
Are your computers the same now as then? Or would they be able to ask for traffic more quickly and possibly saturate your local line to the exclusion of other traffic (like DNS)?
The paragraph above refers mainly to the same ADSL pipe, and the same computers, with the same software. Only the router changed, about a year ago, and then my DNS problems started. The laptops have met other places with different routers. And I have been on other places, with different computers, all configured to use their local router as DNS server.
As someone else mentioned, your newer model router might have bigger io-buffers, and might give better download performance, but worse interactive performance during a download.
It is a better and newer router, more capable, connected on the same old 1 mbit/s pipe. So no, I can not accept that it performs worse, and just on a single service.
Until your DNS traffic is prioritized above the "ACK"s on download streams, which many home routers have implemented to improve throughput, high download saturation may slow down DNS communication -- especially where the resolution is done on your end (vs. always using someone else's DNS server, maybe your ISP's or google's).
The ACKS from the DNS traffic have to compete with your download traffic, and unless you use ingress filtering, DNS could become unresponsive due to the download.
This effect can be worsened by DNS's defaulting to UDP as it doesn't have tcp's auto-correction mechanisms.
also, on QOS, everything else doesn't need to set QOS.
Only the traffic you want to prioritize. Traffic w/o the QOS settings is placed in "the bulk" is given "normal" "best-effort" -- so it can speed up some traffic by prioritizing some traffic over 'bulk' (unrated).
All that applies as well to my DNS cache server on my computer, which traversing the same "saturated" router, manages to do DNS queries just fine, with a saturated internet pipe. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
By asking the DNS server of my ISP, which will respond directly if it has the answer, or query the root servers for me. This diminishes the load on the root servers, and is considered the polite behaviour.
For those who don't keep DNS running on a server, that's probably true. For those who keep DNS running on a server, the expire time for the root servers is 3600000s or 42 days. If the load increases too much on the root servers, I'm pretty sure they could increase that.
So no, I can not accept that it performs worse, and just on a single service.
---- And how many other services do you run UDP with -- which is likely the default for lower-powered routers doing DNS resolution?
Until your DNS traffic is prioritized above the "ACK"s on download streams,
This effect can be worsened by DNS's defaulting to UDP as it doesn't have tcp's auto-correction mechanisms.
also, on QOS, everything else doesn't need to set QOS.
All that applies as well to my DNS cache server on my computer, which traversing the same "saturated" router, manages to do DNS queries just fine, with a saturated internet pipe.
---- 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. 2) DNS over TCP will benefit from the most common end-user optimization in home equipment (if there is any) --- prioritizing 'ACKS'. 3) DNS over UDP won't get that benefit as it doesn't use TCP ACKS. 4) Because UDP is unreliable, it may be getting dropped more often than a similar connection over TCP -- those timeouts are expensive in terms of time. 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. 6). if you are querying your ISP or google, you are using 'fat pipes' for all but the last leg to your house, which is the same regardless of source. This strongly affects response time. 7. As mentioned previously, if you have a smaller router doing lookups, it will likely not have the cache that your ISP would, so it may not be able to hold root servers in cache for 42 days. So there multiple reasons why DNS lookups from your PC through your ISP are very different from DNS lookups performed by your router. There are likely more. Once you get into to doing benchmarks, you start to realize how many variables it takes to keep things "relatively constant". Whether or not any of those are an issue in your specific case or whether or not some other issue is, is an unknown until you do measurements and traffic analysis, which are 'greek' (or is that 'geek?) to most people... I'm not saying you should learn such arcana, but I am saying you shouldn't rule out things based on cursory knowledge, either. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-14 11:39, Linda Walsh wrote:
Carlos E. R. wrote:
By asking the DNS server of my ISP, which will respond directly if it has the answer, or query the root servers for me. This diminishes the load on the root servers, and is considered the polite behaviour.
For those who don't keep DNS running on a server, that's probably true.
For those who keep DNS running on a server, the expire time for the root servers is 3600000s or 42 days. If the load increases too much on the root servers, I'm pretty sure they could increase that.
I would consider doing that for more serious usage than mine :-)
So no, I can not accept that it performs worse, and just on a single service.
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. Internet traffic is mostly pop/imap/smtp/nntp/http and a few dns queries. Other things at times, like emule, svn, etc. 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
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.
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. 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.
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.
6). if you are querying your ISP or google, you are using 'fat pipes' for all but the last leg to your house, which is the same regardless of source. This strongly affects response time.
Of course.
7. As mentioned previously, if you have a smaller router doing lookups, it will likely not have the cache that your ISP would, so it may not be able to hold root servers in cache for 42 days.
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: cer@Telcontar:~> dig smtp.telefonica.net ; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> smtp.telefonica.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22149 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 25 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;smtp.telefonica.net. IN A ;; ANSWER SECTION: smtp.telefonica.net. 184 IN A 86.109.99.70 ;; AUTHORITY SECTION: . 5573 IN NS c.root-servers.net. . 5573 IN NS m.root-servers.net. . 5573 IN NS i.root-servers.net. . 5573 IN NS a.root-servers.net. . 5573 IN NS e.root-servers.net. . 5573 IN NS g.root-servers.net. . 5573 IN NS f.root-servers.net. . 5573 IN NS k.root-servers.net. . 5573 IN NS d.root-servers.net. . 5573 IN NS j.root-servers.net. . 5573 IN NS h.root-servers.net. . 5573 IN NS b.root-servers.net. . 5573 IN NS l.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net. 191424 IN A 198.41.0.4 a.root-servers.net. 193089 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 194508 IN A 192.228.79.201 b.root-servers.net. 32436 IN AAAA 2001:500:84::b c.root-servers.net. 69101 IN A 192.33.4.12 c.root-servers.net. 4779 IN AAAA 2001:500:2::c d.root-servers.net. 105809 IN A 199.7.91.13 d.root-servers.net. 28599 IN AAAA 2001:500:2d::d e.root-servers.net. 200517 IN A 192.203.230.10 f.root-servers.net. 58737 IN A 192.5.5.241 f.root-servers.net. 4780 IN AAAA 2001:500:2f::f g.root-servers.net. 201930 IN A 192.112.36.4 h.root-servers.net. 230382 IN A 128.63.2.53 h.root-servers.net. 55823 IN AAAA 2001:500:1::803f:235 i.root-servers.net. 230382 IN A 192.36.148.17 i.root-servers.net. 34338 IN AAAA 2001:7fe::53 j.root-servers.net. 232769 IN A 192.58.128.30 j.root-servers.net. 20143 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 89299 IN A 193.0.14.129 k.root-servers.net. 30023 IN AAAA 2001:7fd::1 l.root-servers.net. 119048 IN A 199.7.83.42 l.root-servers.net. 62187 IN AAAA 2001:500:3::42 m.root-servers.net. 66051 IN A 202.12.27.33 m.root-servers.net. 26222 IN AAAA 2001:dc3::35 ;; Query time: 114 msec ;; SERVER: 192.168.1.14#53(192.168.1.14) ;; WHEN: Mon Jul 14 15:56:18 CEST 2014 ;; MSG SIZE rcvd: 788 cer@Telcontar:~> 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 I wanted to find out was the timeout, anyhow... In fact, that's one of the addresses that nags me, because when I want to send an email during a busy time (full pipe), they fail simply because my postfix can not verify my own email address. Even if I did send an email a while before, it doesn't remember the address. And it is bind, no memory restraints. Not the router.
So there multiple reasons why DNS lookups from your PC through your ISP are very different from DNS lookups performed by your router. There are likely more. Once you get into to doing benchmarks, you start to realize how many variables it takes to keep things "relatively constant".
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.
Whether or not any of those are an issue in your specific case or whether or not some other issue is, is an unknown until you do measurements and traffic analysis, which are 'greek' (or is that 'geek?) to most people...
I'm not saying you should learn such arcana, but I am saying you shouldn't rule out things based on cursory knowledge, either.
Ok, but none of that benefits me at present. The basic problem is that my router does not do QoS, and does not prioritize DNS packets. So when the pipe is full, they don't get out, or in, simple as that... I have done some BW configuration on it, and maybe it works, maybe not. We'll see. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
cer@Telcontar:~> dig smtp.telefonica.net
; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> smtp.telefonica.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22149 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 25
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;smtp.telefonica.net. IN A
;; ANSWER SECTION: smtp.telefonica.net. 184 IN A 86.109.99.70
;; AUTHORITY SECTION: . 5573 IN NS c.root-servers.net. . 5573 IN NS m.root-servers.net. . 5573 IN NS i.root-servers.net. . 5573 IN NS a.root-servers.net. . 5573 IN NS e.root-servers.net. . 5573 IN NS g.root-servers.net. . 5573 IN NS f.root-servers.net. . 5573 IN NS k.root-servers.net. . 5573 IN NS d.root-servers.net. . 5573 IN NS j.root-servers.net. . 5573 IN NS h.root-servers.net. . 5573 IN NS b.root-servers.net. . 5573 IN NS l.root-servers.net.
;; ADDITIONAL SECTION: a.root-servers.net. 191424 IN A 198.41.0.4 a.root-servers.net. 193089 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 194508 IN A 192.228.79.201 b.root-servers.net. 32436 IN AAAA 2001:500:84::b c.root-servers.net. 69101 IN A 192.33.4.12 c.root-servers.net. 4779 IN AAAA 2001:500:2::c d.root-servers.net. 105809 IN A 199.7.91.13 d.root-servers.net. 28599 IN AAAA 2001:500:2d::d e.root-servers.net. 200517 IN A 192.203.230.10 f.root-servers.net. 58737 IN A 192.5.5.241 f.root-servers.net. 4780 IN AAAA 2001:500:2f::f g.root-servers.net. 201930 IN A 192.112.36.4 h.root-servers.net. 230382 IN A 128.63.2.53 h.root-servers.net. 55823 IN AAAA 2001:500:1::803f:235 i.root-servers.net. 230382 IN A 192.36.148.17 i.root-servers.net. 34338 IN AAAA 2001:7fe::53 j.root-servers.net. 232769 IN A 192.58.128.30 j.root-servers.net. 20143 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 89299 IN A 193.0.14.129 k.root-servers.net. 30023 IN AAAA 2001:7fd::1 l.root-servers.net. 119048 IN A 199.7.83.42 l.root-servers.net. 62187 IN AAAA 2001:500:3::42 m.root-servers.net. 66051 IN A 202.12.27.33 m.root-servers.net. 26222 IN AAAA 2001:dc3::35
When I did the same, I got this: # dig smtp.telefonica.net ; <<>> DiG 9.4.2 <<>> smtp.telefonica.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34049 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUESTION SECTION: ;smtp.telefonica.net. IN A ;; ANSWER SECTION: smtp.telefonica.net. 299 IN A 86.109.99.70 ;; AUTHORITY SECTION: telefonica.net. 299 IN NS artemis.ttd.net. telefonica.net. 299 IN NS marianela.tsm.es. ;; ADDITIONAL SECTION: marianela.tsm.es. 172799 IN A 194.224.100.67
;; Query time: 114 msec ;; SERVER: 192.168.1.14#53(192.168.1.14) ;; WHEN: Mon Jul 14 15:56:18 CEST 2014 ;; MSG SIZE rcvd: 788
cer@Telcontar:~>
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.
Add '+trace' to your dig options, then try again. I have seen the same result sometimes, I don't know why, but usually +trace will tell you exactly what was queried etc.
In fact, that's one of the addresses that nags me, because when I want to send an email during a busy time (full pipe), they fail simply because my postfix can not verify my own email address. Even if I did send an email a while before, it doesn't remember the address. And it is bind, no memory restraints. Not the router.
The first cache is in nscd, then bind, then uplink name-servers.
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.
It is an interesting issue, definitely - even if it may not be worth pursuing.
Ok, but none of that benefits me at present. The basic problem is that my router does not do QoS, and does not prioritize DNS packets. So when the pipe is full, they don't get out, or in, simple as that...
Just out of curiosity, have you tried assigning a QoS class to port 53 (on the originating machine) ? It is easily done with iptables. -- Per Jessen, Zürich (16.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-14 19:33, Per Jessen wrote:
Carlos E. R. wrote:
When I did the same, I got this:
I'm now getting a similar one, too.
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.
Add '+trace' to your dig options, then try again. I have seen the same result sometimes, I don't know why, but usually +trace will tell you exactly what was queried etc.
Ah. Yes, I forgot that one.
cer@Telcontar:~> dig +trace smtp.telefonica.net
; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> +trace smtp.telefonica.net ;; global options: +cmd . 13036 IN NS b.root-servers.net. . 13036 IN NS i.root-servers.net. . 13036 IN NS f.root-servers.net. . 13036 IN NS k.root-servers.net. . 13036 IN NS j.root-servers.net. . 13036 IN NS a.root-servers.net. . 13036 IN NS h.root-servers.net. . 13036 IN NS e.root-servers.net. . 13036 IN NS d.root-servers.net. . 13036 IN NS l.root-servers.net. . 13036 IN NS c.root-servers.net. . 13036 IN NS m.root-servers.net. . 13036 IN NS g.root-servers.net. . 274158 IN RRSIG NS 8 0 518400 20140718000000 20140710230000 8230 . op58oBsyuAXbwW21UhSYx0Tlf+cqFAhukCd8G6gYuklLD8VlihgAe69e f9+jTZU5O2F9l9u5izYQecpIOOQf3TeyK9VwH1K24pjqde8vgyvFZniK Wamql+IcBrMntpstPhP5gbePC9Px+YYYlVZ4d8dM/wKXw3ZMyxTASaUh LGM= ;; Received 913 bytes from 192.168.1.14#53(192.168.1.14) in 1762 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 192.58.128.30#53(j.root-servers.net) in 1207 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.12.94.30#53(e.gtld-servers.net) in 243 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(artemis.ttd.net) in 55 ms
cer@Telcontar:~>
It takes about five seconds... I tried 2 or three times, and every time it tries a different route, but starting at the root servers. This command does not appear to cache the answer. "host -v ..." does.
In fact, that's one of the addresses that nags me, because when I want to send an email during a busy time (full pipe), they fail simply because my postfix can not verify my own email address. Even if I did send an email a while before, it doesn't remember the address. And it is bind, no memory restraints. Not the router.
The first cache is in nscd, then bind, then uplink name-servers.
Yep.
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.
It is an interesting issue, definitely - even if it may not be worth pursuing.
Ok, but none of that benefits me at present. The basic problem is that my router does not do QoS, and does not prioritize DNS packets. So when the pipe is full, they don't get out, or in, simple as that...
Just out of curiosity, have you tried assigning a QoS class to port 53 (on the originating machine) ? It is easily done with iptables.
No, I haven't. I would have to study how to do it. But it would only benefit one machine, not the rest in the house. If it works I could apply the same thing to all Linus computers, but not to the "gadgets". By the way, in the bandwith adjustment on my router, which I posted before, I have reserved a minimal bandwidth to to my local machines to connect to outside on port 53. However, the router itself is excluded from the list... the configuration form rejects it. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
It takes about five seconds... I tried 2 or three times, and every time it tries a different route, but starting at the root servers. This command does not appear to cache the answer. "host -v ..." does.
"+trace" is not supposed to cache the response. It is supposed to turn off recursive responses and it *traces* the _delegation_ path from the root servers you have config'ed, and f
Ok, but none of that benefits me at present. The basic problem is that my router does not do QoS, and does not prioritize DNS packets. So when the pipe is full, they don't get out, or in, simple as that...
Which is one of the main reasons for using a PC. If energy is important, you can use a laptop processor w/SSD or a 'celeron' type processor -- even an 'atom'... if you can run suse linux on it, it should be fine. That way you can dictate traffic policy. Otherwise you are complaining about something you can't really change. I.e. By not replacing your ISP's router w/your own, you are saying that whatever policy your ISP router implements is "fine". Asking on here for solutions is of marginal benefit, as the bottleneck isn't on a suse machine. You *can* control traffic on your home network, but only at the gateway router can you control all the traffic. You could use the gateway router IF all your home traffic went through your suse-linux box before going to the router. You don't have to use "QOS", .. but then you need to do some other traffic filtering -- like wondershaper -- and *adapt* the "ifb" (incoming traffic control) to wondersahper. "ifb" isn't QOS specific. The *only reason* I suggested it is that it is the only script I know of in the suse distribution that can do input filtering -- other than that, we (you and I) don't really need QOS. **B*U*T*** -- the above still requires that you be able to run suse software (or your own version of linux) on the router. If you can't, then same issue mentioned above -- problem is on a box where we can't replace SW and kernel. If that's the case, then list would be of minimal usefulness (someone might know how to do some of these things on your router, but it wouldn't be suse specific knowledge). Note -- none of that is meant to tell you you should not discuss it here, or you should take it elsewhere (it IS an interesting topic), just that if you do discuss such on this list, there are limits as to what can be done when the problem isn't on a suse box but on a router.
By the way, in the bandwith adjustment on my router, which I posted before, I have reserved a minimal bandwidth to to my local machines to connect to outside on port 53. However, the router itself is excluded from the list... the configuration form rejects it.
--- Maybe get a new router? But a low-power computer that can run suse, might be more advantageous. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-15 03:54, Linda Walsh wrote:
Carlos E. R. wrote:
Which is one of the main reasons for using a PC. If energy is important, you can use a laptop processor w/SSD or a 'celeron' type processor -- even an 'atom'... if you can run suse linux on it, it should be fine.
Only a PC does not suffice. Three machines are needed: 1) The original adls router, or an equivalent one, acting in pass-through mode, like a "modem" from ADSL to ethernet. Alternatively, I have to buy a card that knows ADSL for the computer. 2) A computer, with at least 2 ethernet ports (routing internet WAN to LAN), and wireless card with good antennas. 3) A switch. That's a lot for a home system. It would be cheaper to flash the router instead. There are good and open firmwares around.
That way you can dictate traffic policy. Otherwise you are complaining about something you can't really change. I.e. By not replacing your ISP's router w/your own, you are saying that whatever policy your ISP router implements is "fine".
In fact, that router is not my ISP router. I bought one to replace theirs.
Asking on here for solutions is of marginal benefit, as the bottleneck isn't on a suse machine.
I know. But surely I'm not the first one to hit this kind of problem, and people may know. And in fact, I have got the ideas here that guided me to solve the issue, because as I said already, it is solved. Or so it seems. I said that some posts back already.
By the way, in the bandwith adjustment on my router, which I posted before, I have reserved a minimal bandwidth to to my local machines to connect to outside on port 53. However, the router itself is excluded from the list... the configuration form rejects it.
Maybe get a new router? But a low-power computer that can run suse, might be more advantageous.
/That/ one is the new router, actually. :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-07-15 03:54, Linda Walsh wrote:
Carlos E. R. wrote:
Which is one of the main reasons for using a PC. If energy is important, you can use a laptop processor w/SSD or a 'celeron' type processor -- even an 'atom'... if you can run suse linux on it, it should be fine.
Only a PC does not suffice.
Three machines are needed:
1) The original adls router, or an equivalent one, acting in pass-through mode, like a "modem" from ADSL to ethernet.
Typically, a router can be put into bridge mode. -- Per Jessen, Zürich (18.0°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-15 08:01, Per Jessen wrote:
Carlos E. R. wrote:
1) The original adls router, or an equivalent one, acting in pass-through mode, like a "modem" from ADSL to ethernet.
Typically, a router can be put into bridge mode.
True. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-07-15 08:01, Per Jessen wrote:
Carlos E. R. wrote:
1) The original adls router, or an equivalent one, acting in pass-through mode, like a "modem" from ADSL to ethernet.
Typically, a router can be put into bridge mode.
And then your "routing" (and traffic prioritization, if wanted) could be done on your PC. The only thing you mentioned that such might not cover is wireless -- if your PC doesn't have wireless capability. (I've never gotten into wireless due to bad reception and interference issues). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/15/2014 06:23 PM, Linda Walsh wrote:
Carlos E. R. wrote:
On 2014-07-15 08:01, Per Jessen wrote:
Carlos E. R. wrote:
1) The original adls router, or an equivalent one, acting in pass-through mode, like a "modem" from ADSL to ethernet.
Typically, a router can be put into bridge mode.
And then your "routing" (and traffic prioritization, if wanted) could be done on your PC.
The only thing you mentioned that such might not cover is wireless -- if your PC doesn't have wireless capability. (I've never gotten into wireless due to bad reception and interference issues).
In addition to the Linux computer based firewall/router that I mentioned earlier, I have a WiFi access point that works very well. It doesn't even have a router function. Also, since it uses PoE, I can mount it in any convenient location, without worrying about having AC power nearby. I mounted it up on the wall of my laundry room, roughly near the middle of my condo. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/14/2014 7:26 PM, Carlos E. R. wrote:
Only a PC does not suffice.
Three machines are needed:
1) The original adls router, or an equivalent one, acting in pass-through mode, like a "modem" from ADSL to ethernet. Alternatively, I have to buy a card that knows ADSL for the computer. 2) A computer, with at least 2 ethernet ports (routing internet WAN to LAN), and wireless card with good antennas. 3) A switch.
That's a lot for a home system.
Heh, you should see my home system... But wait, I'm confused. Havent been following the whole thread, but last I was following it, your problems were pretty much solved by just not using the DNS server on the router. The router was still able to route, just not route and do dns. Or did I miss something? Turn off the DNS in the router, put up a Raspberry Pi to do DNS via any fast DNS providers you can find. http://www.raspberrypi.org/forums/viewtopic.php?t=46154 - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAlPE3RkACgkQv7M3G5+2DLLZbgCbBSdP5OXseLnYWecfgrXcFY0k jSIAn3mpXOEDixQyveJ9SMqwJzLhChqr =s9dj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-15 09:49, John Andersen wrote:
On 7/14/2014 7:26 PM, Carlos E. R. wrote:
Only a PC does not suffice.
Three machines are needed:
1) The original adls router, or an equivalent one, acting in pass-through mode, like a "modem" from ADSL to ethernet. Alternatively, I have to buy a card that knows ADSL for the computer. 2) A computer, with at least 2 ethernet ports (routing internet WAN to LAN), and wireless card with good antennas. 3) A switch.
That's a lot for a home system.
Heh, you should see my home system...
And mine - LOL. Just that part is "simple".
But wait, I'm confused. Havent been following the whole thread, but last I was following it, your problems were pretty much solved by just not using the DNS server on the router.
Correct. Unfortunately, although it works better, it doesn't always. So what I did later was find out how my router, which claims to do "bandwidth control" can be configured to do that. I found that out, and now I'm trying to observe it it works or not.
The router was still able to route, just not route and do dns. Or did I miss something?
No, but Linda has not noticed that it was solved, more or less :-)
Turn off the DNS in the router, put up a Raspberry Pi to do DNS via any fast DNS providers you can find. http://www.raspberrypi.org/forums/viewtopic.php?t=46154
:-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 07/15/2014 03:49 AM, John Andersen wrote:
Turn off the DNS in the router, put up a Raspberry Pi to do DNS via any fast DNS providers you can find. http://www.raspberrypi.org/forums/viewtopic.php?t=46154
I have dnsmasq running here. My firewall/router is an old computer running Linux. Dnsmasq is a caching DNS server that also provides look up for local devices, with both IPv4 and IPv6 addresses. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-15 13:56, James Knott wrote:
I have dnsmasq running here. My firewall/router is an old computer running Linux. Dnsmasq is a caching DNS server that also provides look up for local devices, with both IPv4 and IPv6 addresses.
Yes, I use it on two laptops here. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
It takes about five seconds... I tried 2 or three times, and every time it tries a different route, but starting at the root servers. This command does not appear to cache the answer. "host -v ..." does.
Yes, you're right - "dig" talks directly to the nameserver, whereas "host" uses the resolver which in turn uses nscd.
Just out of curiosity, have you tried assigning a QoS class to port 53 (on the originating machine) ? It is easily done with iptables.
No, I haven't. I would have to study how to do it.
iptables -A PREROUTING -t mangle -p udp --dport domain -j TOS --set-tos Minimize-Delay iptables -A PREROUTING -t mangle -p tcp --dport domain -j TOS --set-tos Minimize-Delay
But it would only benefit one machine, not the rest in the house.
Yes, but if it works, your router would appear to have some idea of how to prioritize traffic correctly. -- Per Jessen, Zürich (17.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-15 07:47, Per Jessen wrote:
Carlos E. R. wrote:
It takes about five seconds... I tried 2 or three times, and every time it tries a different route, but starting at the root servers. This command does not appear to cache the answer. "host -v ..." does.
Yes, you're right - "dig" talks directly to the nameserver, whereas "host" uses the resolver which in turn uses nscd.
Ah. Ok. But the nameserver is mine, in this machine. Should it not cache? Unless when you say "+trace" it does not cache.
Just out of curiosity, have you tried assigning a QoS class to port 53 (on the originating machine) ? It is easily done with iptables.
No, I haven't. I would have to study how to do it.
iptables -A PREROUTING -t mangle -p udp --dport domain -j TOS --set-tos Minimize-Delay iptables -A PREROUTING -t mangle -p tcp --dport domain -j TOS --set-tos Minimize-Delay
But it would only benefit one machine, not the rest in the house.
Yes, but if it works, your router would appear to have some idea of how to prioritize traffic correctly.
Ah, I see. Ok, one thing more to my to-do list. I have some "real world" chores waiting... Thanks :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-07-15 07:47, Per Jessen wrote:
Carlos E. R. wrote:
It takes about five seconds... I tried 2 or three times, and every time it tries a different route, but starting at the root servers. This command does not appear to cache the answer. "host -v ..." does.
Yes, you're right - "dig" talks directly to the nameserver, whereas "host" uses the resolver which in turn uses nscd.
Ah. Ok.
But the nameserver is mine, in this machine. Should it not cache?
Yes, it should. You can verify it with dig - pick something you have never looked up, maybe "www.tagi.ch" - on the first dig, you see a TTL of 900, on subsequent digs, you should see the TTL decreasing. -- Per Jessen, Zürich (18.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-15 12:35, Per Jessen wrote:
Carlos E. R. wrote:
But the nameserver is mine, in this machine. Should it not cache?
Yes, it should. You can verify it with dig - pick something you have never looked up, maybe "www.tagi.ch" - on the first dig, you see a TTL of 900, on subsequent digs, you should see the TTL decreasing.
True. ;; Query time: 157 msec ... ;; Query time: 0 msec But if I ask for "telefonica.es" it takes 88 ms, when that address was used less than an hour ago, maybe minutes. Supposedly the sites (not me) define how long to cache an address. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-07-15 12:35, Per Jessen wrote:
Carlos E. R. wrote:
But the nameserver is mine, in this machine. Should it not cache?
Yes, it should. You can verify it with dig - pick something you have never looked up, maybe "www.tagi.ch" - on the first dig, you see a TTL of 900, on subsequent digs, you should see the TTL decreasing.
True.
;; Query time: 157 msec
...
;; Query time: 0 msec
But if I ask for "telefonica.es" it takes 88 ms, when that address was used less than an hour ago, maybe minutes. Supposedly the sites (not me) define how long to cache an address.
Yes, that is the TTL = Time-To-Live. You see it in every dig. dig telefonica.es ; <<>> DiG 9.4.1-P1 <<>> telefonica.es ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41475 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;telefonica.es. IN A ;; ANSWER SECTION: telefonica.es. 300 IN A 194.224.58.10 ^^^ TTL = 5 minutes. -- Per Jessen, Zürich (18.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
On 2014-07-15 04:28, Linda Walsh wrote:
Carlos E. R. wrote:
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.
But it is. Trust me, I know it is. (because unless I do, the router complains of bad syntax and that it is waiting for a valid, non-zero, address. Remember that these things are not designed by British, North Americans, or Australians. You can not expect to understand how to use them by reading form names, menu entries, help files, or a hundred pages of documentation, even if it is English (and I did read it, start to end) ;-) Example of documentation: +++········ Address. Here you write the address. See photo ········++- And you get a photo of the screen, with no address written, so you can not even guess what to write there - unless you happen to know what an address is. And of course, the manual is full of photos, so it is huge. And then, when you try, it says that 1.1.1.1 is not a valid address... Believe me, I do know, now, what to write in the damn form. I spent hours to find out. Why are not these things designed and built in Germany, or Canada? Gosh, then I could hope to understand them! At least, they could hire good technical writers!
Does it want destination IP's or source IP's?
It wants the local IP addresses of my machines, on the LAN side of the router.
Description doesn't really tell you. It certainly doesn't specify if the policy is for TCP, UDP or ICMP (for example).
That's the "All" in the description. I said so somewhere.
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.).
I did say brand and model, it is in this post some lines up :-) I'm just saying that in my router it is done that way, no matter how absurd it looks, so that anybody looking in the archive one day can find that info.
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.
Nope. The router can not intercept my DNS queries and change them anyway, they are just packets to be routed. Only when I ask the router for solving DNS, it can do what it wishes. That is, I'm no longer doing: forwarders { 192.168.1.1; }; but forwarders { 80.58.61.250; 80.58.61.254; 208.67.222.222; 8.8.8.8; }; I said so several posts back.
If you config your PC DNS daemon to another DNS server, it may easily be TCP all the way.
I did... days ago, and posts ago. I said so here. And I said it apparently solved most of the issue.
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.
PC. Bind.
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
Se previous answer.
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.
Can't be done. The outside of the router is a phone line. Gosh! Don't you know what an ADSL router is? It is not a business class CISCO router and ISP big client pipe!
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.
That says the telefonica.net servers have a 40+ hour lifetime.
Ok.
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*..
Don't complain to me. That's how bind does things, as openSUSE ships it. But I don't think it is doing that, anyway.
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.
search valinor nameserver 192.168.1.14 That is, it has to query my own DNS server, in this same machine. And the address solves: Telcontar:~ # host 192.168.1.14 14.1.168.192.in-addr.arpa domain name pointer Telcontar.valinor. Telcontar:~ # host Telcontar.valinor Telcontar.valinor has address 192.168.1.14 Telcontar.valinor mail is handled by 10 Telcontar.valinor. Telcontar:~ #
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.
And I said that I found out how to tell my router to do "some" of that. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
But it is. Trust me, I know it is.
I believe you -- I.e. proof is in the pudding (working or not), but was just saying it seems weird.
But you see, I'm using my PC DNS daemon, aka bind. And it times out.
I thought you said it was timing out only when you used the modem to resolve DNS, but when you pointed your resolver at an ISP or google DNS, it worked.
---- Doesn't matter. Your PC DNS daemon likely uses TCP to talk to the router, and the router likely uses UDP to talk upstream.
Nope. The router can not intercept my DNS queries and change them anyway, they are just packets to be routed. Only when I ask the router for solving DNS, it can do what it wishes.
--- What do you mean 'nope' -- that the PC DNS daemon doesn't use TCP or that the modem doesn't use UDP? Note that there is no "then" in that sentence, but an 'and' (they are independent clauses). The point about having your DNS resolved by your router was that the information in it -- that was programmed by your ISP, presumably, seems "off". If you resolve directly from your ISP, it is not surprising if it showed the same peculiarity. BTW. Something that performs routing decisions is usually called a router, while Something that adapts an external line and a computer connection is most often called a "modem" (i.e. I have a cable modem, for example).
If you config your PC DNS daemon to another DNS server, it may easily be TCP all the way.
I did... days ago, and posts ago. I said so here. And I said it apparently solved most of the issue.
I thought the whole issue was that DNS wasn't working on the modem -- not that you couldn't workaround it. I seem to remember you saying you had multiple devices that needed to be hooked to the modem for DNS resolution. Is that no longer the case and/or no longer a requirement?
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.
PC. Bind.
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
Se previous answer.
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.
Can't be done. The outside of the router is a phone line.
--- Oi! Outside my modem is a cable -- BUT I can listen into the conversation on the other side in bridge mode.
Gosh! Don't you know what an ADSL router is? It is not a business class CISCO router and ISP big client pipe!
---- It's not even a router from the sound of it, but more what I'm used to being called a modem. Same thing I have, but instead of a phone line, I have a TV-cable service.
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.
Is that all you have in /etc/named.conf, as it doesn't appear to be valid: When I try to verify your named.conf file, I get:
named-checkconf -p -z /tmp/named.conf /tmp/named.conf:1: unknown option 'forwarders' /tmp/named.conf:2: unknown option 'forward'
BTW, if you are "addressing me" in an email, it would be helpful if you include my name in the recipients list. Otherwise, I have no way of knowing the email is 'addressing' (talking) to me. Thanks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-15 09:21, Linda Walsh wrote:
Carlos E. R. wrote:
But it is. Trust me, I know it is.
I believe you -- I.e. proof is in the pudding (working or not), but was just saying it seems weird.
Yes, I know it is weird. How many consumer-grade gadgets manufactured somewhere in Asia have you seen with properly written English instructions? >:-) (other European languages get worse fate)
But you see, I'm using my PC DNS daemon, aka bind. And it times out.
I thought you said it was timing out only when you used the modem to resolve DNS, but when you pointed your resolver at an ISP or google DNS, it worked.
I configured my bind to ask first my ISP DNS server, instead of the previous config which was to ask my router local DNS-cache-whatever. And yes, that configuration works much better. It times out fewer times. And, for the rest of the non-configurable gadgets in the house, I changed the config in the router itself (dhcp section) to do the same. And later, I changed the (obscure) bandwidth control in the router, which seems to work better than the above . But all the time, I have been using bind in my computer, since many years. And despite it been supposed to cache data, it times out asking for data that should already be cached.
---- Doesn't matter. Your PC DNS daemon likely uses TCP to talk to the router, and the router likely uses UDP to talk upstream.
Nope. The router can not intercept my DNS queries and change them anyway, they are just packets to be routed. Only when I ask the router for solving DNS, it can do what it wishes.
--- What do you mean 'nope' -- that the PC DNS daemon doesn't use TCP or that the modem doesn't use UDP? Note that there is no "then" in that sentence, but an 'and' (they are independent clauses).
Look. If I tell my PC's bind to do the asking to my router, then it is my router who does all the real asking, and it does as it wants, udp, tcp, whatever. I have no control on it. If I tell my PC's bind to do the asking to my ISP DNS servers, then my PC has control, and uses whatever it sees fit. If it uses TCP, the router in the middle just routes the packets.
The point about having your DNS resolved by your router was that the information in it -- that was programmed by your ISP, presumably, seems "off". If you resolve directly from your ISP, it is not surprising if it showed the same peculiarity.
This model I bought on a computer shop, it is not supplied by the ISP. It is prepared for use in many different countries and many different providers. It self-configurates. It gets the outside DNS to use automatically during the ppp negotiation with my ISP, presumably, it is not hardcoded - but I can configure a DNS address, if I want. It appears to have some kind of limited cache dns server inside.
BTW. Something that performs routing decisions is usually called a router, while Something that adapts an external line and a computer connection is most often called a "modem" (i.e. I have a cable modem, for example).
Home ADSL routers do both. And they also include a small switch, and a WiFi access point.
If you config your PC DNS daemon to another DNS server, it may easily be TCP all the way.
I did... days ago, and posts ago. I said so here. And I said it apparently solved most of the issue.
I thought the whole issue was that DNS wasn't working on the modem -- not that you couldn't workaround it. I seem to remember you saying you had multiple devices that needed to be hooked to the modem for DNS resolution. Is that no longer the case and/or no longer a requirement?
Yes, that is correct. I have devices that can not be configured at all (they use dhcp, not optional). However, I can, in the dhcp section of the router, set up a different DNS address, so that these devices do not ask my router for DNS solving, but whatever outside or local address I put in there. And I wrote in there one address from my ISP, and another from google. Then, later, I found out how to tell my router to do some bandwidth control, reserving 1K for DNS traffic. And this /seems/ to work even better.
Can't be done. The outside of the router is a phone line.
--- Oi! Outside my modem is a cable -- BUT I can listen into the conversation on the other side in bridge mode.
If I put it in bridge mode then I have to get something else as router/switch.
Gosh! Don't you know what an ADSL router is? It is not a business class CISCO router and ISP big client pipe!
---- It's not even a router from the sound of it, but more what I'm used to being called a modem. Same thing I have, but instead of a phone line, I have a TV-cable service.
These things are home/soho routers, and include all functions: modem/router/switch/wifi-access-point. In my case, also adsl/eth-cable/3G-dongle. Plus, printer via usb, and file-server via usb. And they handle dhcp, vpn, dyndns, and I forget what more. All in one.
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.
Is that all you have in /etc/named.conf, as it doesn't appear to be valid:
When I try to verify your named.conf file, I get:
named-checkconf -p -z /tmp/named.conf /tmp/named.conf:1: unknown option 'forwarders' /tmp/named.conf:2: unknown option 'forward'
Telcontar:~ # named-checkconf /etc/named.conf Telcontar:~ # You can not put those lines alone, they need a context: options { directory "/etc/named"; dump-file "/var/log/named_dump.db"; statistics-file "/var/log/named.stats"; # neither file are created # forwarders { 192.168.1.1; }; #forwarders { 8.8.8.8; 208.67.222.222; }; forwarders { 80.58.61.250; 80.58.61.254; 208.67.222.222; 8.8.8.8; }; forward first; listen-on-v6 { any; }; notify no; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; include "/etc/named.d/forwarders.conf"; }; and then come the zone configs.
BTW, if you are "addressing me" in an email, it would be helpful if you include my name in the recipients list. Otherwise, I have no way of knowing the email is 'addressing' (talking) to me. Thanks.
You find that out because of this line at the top: "On 2014-07-15 09:21, Linda Walsh wrote:" :-) I only send to the list, except on special request to do otherwise. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
When I have dowloads running, using my full internet pipe, which is just 1 mbit/s ADSL via dedicated router, DNS queries fail, meaning that anything internet related fails, in the entire house. It does not matter what machine is doing the download.
(I can do several downloads at the same time, though)
If your line is maxed out, I can see UDP queries failing, but usually the resolver will then switch to TCP, which should work, even if the line is loaded.
Aparently, the router is not capable of prioritizing and doing two things at the same time, like doing a download, and querying upstream DNSs.
The router might be, but there's no guarantee that the rest of your uplink adheres to any QoS indicators.
What would be the best strategy to at least paliate this?
I have had issues with VoIP quality when a link is fully loaded, but I have never had an issue with DNS. I would at least check to see if your resolver does properly witch to TCP if the UDP queries time out.
At this moment, this machine is using bind, with this config:
forwarders { 192.168.1.1; }; forward first;
which means that it asks my router, which in turn asks my ISP. Maybe I should tell my machine to query some other DNS server outside, instead, in case it is just the router which can not do two things, but it may allow packages to go in or out... :-?
It's worth bypassing your router as a test, certainly. If the router is being maxed out, that might be the problem. -- Per Jessen, Zürich (11.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2014-07-10 at 19:21 +0200, Per Jessen wrote:
Carlos E. R. wrote:
Aparently, the router is not capable of prioritizing and doing two things at the same time, like doing a download, and querying upstream DNSs.
The router might be, but there's no guarantee that the rest of your uplink adheres to any QoS indicators.
True, but the router could reserve some litle bandwidth for itself, so that it can still do DNS. It can control its own download speed, if it wants to.
forwarders { 192.168.1.1; }; forward first;
which means that it asks my router, which in turn asks my ISP. Maybe I should tell my machine to query some other DNS server outside, instead, in case it is just the router which can not do two things, but it may allow packages to go in or out... :-?
It's worth bypassing your router as a test, certainly. If the router is being maxed out, that might be the problem.
And it works... the router is faulty in this respect. I'm using now: forwarders { 8.8.8.8; 208.67.222.222; }; which I'm not happy with, as google learns even more about my usage. I could not learn my ISP DNS from my router. Wait, I can, old logs... Yes, they work. Now I have: forwarders { 80.58.61.250; 80.58.61.254; 208.67.222.222; 8.8.8.8; }; Tested with a large download running.... And the problem can not be my small internet pipe. However, other devices in the house, like my mobile phone, which gets their setting via dhcp from the router, fail. Unless... ok, I just configured my router to give as DNS addresses those listed above, instead of itself. [...] Yep, it works. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO/I80ACgkQtTMYHG2NR9WzogCfbZaORgR7zOWrtRE84GaDXyWu SEsAnjKrjJPfmzqmgw+4qcilqTaTKQZS =2VvO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/07/14 20:37, Carlos E. R. wrote:
On Thursday, 2014-07-10 at 19:21 +0200, Per Jessen wrote:
Carlos E. R. wrote:
Aparently, the router is not capable of prioritizing and doing two things at the same time, like doing a download, and querying upstream DNSs.
The router might be, but there's no guarantee that the rest of your uplink adheres to any QoS indicators.
True, but the router could reserve some litle bandwidth for itself, so that it can still do DNS. It can control its own download speed, if it wants to.
I wonder if its not an issue with bandwidth but processing power? Could be that when you are downloading, it consumes the router's CPU. Thus not even allowing its DNS service to execute. That could explain why its DNS service seems to stall but using an external DNS service does not. Just a thought. Alvin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-11 01:53, Alvin Beach wrote:
On 10/07/14 20:37, Carlos E. R. wrote:
I wonder if its not an issue with bandwidth but processing power? Could be that when you are downloading, it consumes the router's CPU. Thus not even allowing its DNS service to execute. That could explain why its DNS service seems to stall but using an external DNS service does not.
Just a thought.
Yes, I agree, but it can not be CPU. It is absurd, the router is prepared for high speed adsl and wifi (while my adls is slow), and has usb ports for use with printer and file server. Sometimes I have emule running on a computer, and you know that this opens many connections. I have done heavy transfers between ethernet and cable at about 300 megs, the maximum for my wifi, everything working fine. It is just DNS on the router that times out. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/2014 4:37 PM, Carlos E. R. wrote:
I'm using now:
forwarders { 8.8.8.8; 208.67.222.222; };
which I'm not happy with, as google learns even more about my usage. I could not learn my ISP DNS from my router. Wait, I can, old logs...
There is always http://www.opendns.com/home-internet-security/premium-dns/ they have a free service or a paid. - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAlO/NzQACgkQv7M3G5+2DLK8pQCginYHv/b2ehpmMFCp5e7nePIH K0UAn35FdnU6drpRkcYT5ogYbEqJ6wvF =1vH6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-11 03:00, John Andersen wrote:
On 7/10/2014 4:37 PM, Carlos E. R. wrote:
I'm using now:
forwarders { 8.8.8.8; 208.67.222.222; };
which I'm not happy with, as google learns even more about my usage. I could not learn my ISP DNS from my router. Wait, I can, old logs...
There is always http://www.opendns.com/home-internet-security/premium-dns/ they have a free service or a paid.
The second IP above is from them ;-) But I prefer plain DNS servers without second intentions, neither google's, nor opendns's. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Try setting your computer to use 8.8.8.8 in the resolve config. It might be that the router software is just so busy it can't do the lookup rather than not being able to squeeze in one additional packet for dns. On July 10, 2014 9:27:19 AM PDT, "Carlos E. R." <carlos.e.r@opensuse.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I have a nuisance problem.
When I have dowloads running, using my full internet pipe, which is just 1 mbit/s ADSL via dedicated router, DNS queries fail, meaning that anything internet related fails, in the entire house. It does not matter what machine is doing the download.
(I can do several downloads at the same time, though)
Aparently, the router is not capable of prioritizing and doing two things at the same time, like doing a download, and querying upstream DNSs.
What would be the best strategy to at least paliate this?
At this moment, this machine is using bind, with this config:
forwarders { 192.168.1.1; }; forward first;
which means that it asks my router, which in turn asks my ISP. Maybe I should tell my machine to query some other DNS server outside, instead, in case it is just the router which can not do two things, but it may allow packages to go in or out... :-?
- -- Cheers Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlO+vucACgkQtTMYHG2NR9UZGQCdFuztYdNraGwxK7lfFd1g7it/ hcwAn2CFdqbEf6gFRlgAGd3CcjNmpcDv =kUSU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2014-07-10 at 10:24 -0700, John Andersen wrote:
Try setting your computer to use 8.8.8.8 in the resolve config. It might be that the router software is just so busy it can't do the lookup rather than not being able to squeeze in one additional packet for dns.
Just did, and it works. But it can not just be cpu load on the router, it must be something else. Starting with bad design. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlO/JFYACgkQtTMYHG2NR9WUZwCdF8FT4xblW47gCWetv+ZOQPpL z9kAn0Mg4VcA17ZJxKEbxF7N8OTZMsEc =uL08 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/10/2014 11:27 AM, Carlos E. R. wrote:
At this moment, this machine is using bind, with this config:
forwarders { 192.168.1.1; }; forward first;
Get rid of `forward first;` and replace it with `forward only`. Here is a snippet from the bind 8/9 DNS-HOWWTO: The default setting is "forward first", which first asks each of the forwarders, and then tries the normal approach of doing the legwork itself if that fails. This gives the familiar behaviour of gethostbyname() taking an inordinately long time when the link is not up. (or full as in your case) But if "forward only" is set, then BIND gives up when it doesn't get a response from the forwarders, and gethostbyname() returns immediately. Worth a try... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-07-14 19:59, David C. Rankin wrote:
On 07/10/2014 11:27 AM, Carlos E. R. wrote:
At this moment, this machine is using bind, with this config:
forwarders { 192.168.1.1; }; forward first;
Get rid of `forward first;` and replace it with `forward only`. Here is a snippet from the bind 8/9 DNS-HOWWTO:
The default setting is "forward first", which first asks each of the forwarders, and then tries the normal approach of doing the legwork itself if that fails. This gives the familiar behaviour of gethostbyname() taking an inordinately long time when the link is not up. (or full as in your case)
No, it does not take long. It fails, and fails relatively fast, few seconds.
But if "forward only" is set, then BIND gives up when it doesn't get a response from the forwarders, and gethostbyname() returns immediately.
Well, I really prefer getting an answer than a failure. :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (10)
-
Alvin Beach -
Andrey Borzenkov -
auxsvr＠gmail.com -
Carlos E. R. -
Carlos E. R. -
David C. Rankin -
James Knott -
John Andersen -
Linda Walsh -
Per Jessen