View Full Version : Loss of DNS? in Leeds 4 times in the last 6 days
I've been having problems with my broadband. On friday/sunday/tuesday and tonight. It's done it in the evenings (around 8pm to midnight give or take an hour). It's just come back now at 10.57pm.
Basically what happens is I can access emails, but browsing doesn't work.
I put a url (one based in the USA) into neotrace to see what was going on. It gets from Leeds to London in around 6 or 7 hops, all ip's resolve as they should. The node in London doesn't resolve, then after around 25 seconds of waiting it says the response time on that node is around 20ms and then all nodes after that resolve fine until the destination.
For browsing I can't get pages to work. If I really persevere eventually I can get a page up but it's a lot of hassle and not really worth it.
I'm guessing this means ntl are having problems with a DNS server in the London area? Can anyone confirm this?
EDIT: I've just this minute received 2 emails (from a friend, not spam) that I already received before (one yesterday, one 3 days ago)!
At a guess you mean the TeleIC routers in London - the lack of response from them is normal - they have better things to do than respond to icmp requests. :)
...the lack of response from them is normal...Whataver was happening I can assure you it's not normal for the net connection to be dead - no webpages loading, intermittent emails.
greencreeper
25-11-2004, 15:37
Might the times coincide with peak usage - UBR not coping? I await criticism from an NTL tech :D
ProfPete
25-11-2004, 19:32
Basically what happens is I can access emails, but browsing doesn't work.
I put a url (one based in the USA) into neotrace to see what was going on. It gets from Leeds to London in around 6 or 7 hops, all ip's resolve as they should. The node in London doesn't resolve, then after around 25 seconds of waiting it says the response time on that node is around 20ms and then all nodes after that resolve fine until the destination.
Can you post a couple of traceroutes please. Prime candidates are stuff like www.mit.edu and www.harvard.edu for stuff on the american side. www.linx.net will do for this side of the pond.
It's working ok now but I'll do that if it does it again.
DNS timout for pop.ntlworld.com is a frequent occurence for me, as is other times when a site only goes at the second attempt - are there REALLY only two DNS servers for the entire network, or are the addresses regionally mapped?
DNS timeouts began happening again for me in Waltham Forest this week...
What do you mean by a "DNS timeout" ?
It started acting up at 5pm, sites sometimes loading sometimes not, or taking an age to load, with red x's all over the place etc...
It was really bad just before 7pm so I did a couple of traceroutes.
Tracing route to www.mit.edu (http://www.mit.edu/) [18.7.22.83]
over a maximum of 30 hops:
1 16 ms 8 ms 10 ms 10.76.32.1
(it paused 24sec here)
2 16 ms 8 ms 32 ms leed-t2cam1-a-ge96.inet.ntl.com [80.0.54.17]
3 12 ms * 10 ms leed-t2core-a-ge-wan64.inet.ntl.com [80.0.241.41]
4 12 ms 14 ms 24 ms lee-bb-a-so-120-0.inet.ntl.com [62.253.185.17]
5 21 ms * 26 ms lee-bb-b-ae0-0.inet.ntl.com [62.253.187.186]
6 33 ms 16 ms 17 ms ren-bb-a-so-000-0.inet.ntl.com [62.253.185.161]
7 30 ms 34 ms 26 ms bre-bb-b-so-200-0.inet.ntl.com [62.253.185.166]
8 27 ms 30 ms 55 ms telc-ic-1-so-210-0.inet.ntl.com [62.253.188.121]
9 35 ms * 30 ms (it paused 22sec here) 195.66.226.185
10 103 ms 96 ms 95 ms p6-0.core02.jfk01.atlas.cogentco.com [154.54.1.5]
11 * 98 ms 96 ms p15-0.core01.jfk01.atlas.cogentco.com [66.28.4.165]
12 97 ms * 96 ms p12-0.core01.jfk02.atlas.cogentco.com [66.28.4.10]
13 106 ms 108 ms * p5-0.core01.bos01.atlas.cogentco.com [66.28.4.117]
14 104 ms 102 ms 106 ms g7.ba21.b002250-1.bos01.atlas.cogentco.com [66.250.14.206]
15 95 ms 106 ms * mit.demarc.cogentco.com [38.112.2.214]
16 96 ms * 98 ms w92-rtr-1-backbone.mit.edu [18.168.0.25]
17 130 ms 107 ms 107 ms www.mit.edu (http://www.mit.edu/) [18.7.22.83]
Trace complete.
(total time 74sec)
-----------------
Tracing route to nancy.harvard.edu [128.103.60.24]
over a maximum of 30 hops:
1 11 ms 14 ms 8 ms 10.76.32.1
(it paused 24 sec here)
2 28 ms 16 ms 16 ms leed-t2cam1-b-ge96.inet.ntl.com [80.0.55.17]
3 14 ms 17 ms * leed-t2core-b-ge-wan64.inet.ntl.com [80.0.241.169]
4 10 ms 10 ms 9 ms lee-bb-b-so-120-0.inet.ntl.com [62.253.185.21]
5 17 ms * 48 ms ren-bb-a-so-000-0.inet.ntl.com [62.253.185.161]
6 34 ms * 26 ms bre-bb-b-so-200-0.inet.ntl.com [62.253.185.166]
7 31 ms 39 ms 28 ms telc-ic-1-so-210-0.inet.ntl.com [62.253.188.121]
8 31 ms 29 ms * (it paused 20sec here) 195.66.226.185
9 102 ms * 98 ms p6-0.core02.jfk01.atlas.cogentco.com [154.54.1.5]
10 106 ms 106 ms * p15-0.core01.jfk01.atlas.cogentco.com [66.28.4.165]
11 104 ms 98 ms 112 ms p12-0.core01.jfk02.atlas.cogentco.com [66.28.4.10]
12 100 ms 100 ms 100 ms p5-0.core01.bos01.atlas.cogentco.com [66.28.4.117]
13 100 ms 106 ms * g7.ba21.b002250-1.bos01.atlas.cogentco.com [66.250.14.206]
14 * * * Request timed out.
15 116 ms 115 ms 119 ms oxgw2-vl-15-core.net.harvard.edu [128.103.15.15]
16 120 ms 139 ms 116 ms nancy.harvard.edu [128.103.60.24]
Trace complete.
(total time 94sec)
What do you mean by a "DNS timeout" ?Whenever you type a url in your browser, for example www.google.com (http://www.google.com) this has to be looked up on a dns server (basically it's like a big address book). The dns server tells you the ip of the url (for google it's 216.239.51.99). Without knowing the ip you (or your pc) wouldn't know whereabouts in the world the site was hosted on and so wouldn't be able to find it. DNS timeouts are where the dns server doesn't (for whatever reason) tell you the ip, so you can't go to the site.
Erm, I think this explanation is right, someone correct me if it's not.
I *think* that if you have the ip's of sites in your hosts file then you don't need a dns server, but obviously without using the dns server you can only visit the sites who's ip's you've already put into the hosts file.
Hey all new user here.
Well Dave i can say i've been having the exact same problem as you for the past 4days now, at 5pm im not able to view any webpages what so ever. Infact im not allowed todo anything that involves the internet coz it just doesnt work.
The same pattern over and over again now for the past 4 days have been.
5pm i start getting the problem, then at 10:30/11:00pm my connection becomes stable again and everything works fine.
At first i thought "ok must be planned maintenance" so i thought nothing of it but today [Friday] it happened again so i decided to give ntl a ring only to be on hold for 40mins listening to that damn horrible music :mad:. I then gaveup coz i just couldn't be arsed waiting any longer :P
So i went to watch some tv for awhile to come back at 11pm to find everythings working fine, so i decided to do a little search to see if anyone else is actually getting the same problem as me and i found this forum :D
I seriously dont know wtf is going on here and ill prolly try giving ntl another ring tomorrow and pray that im not waiting for another 30-40mins :(
PS, i do live in Leeds and have been having the problem since monday
Whenever you type a url in your browser, for example www.google.com (http://www.google.com) this has to be looked up on a dns server (basically it's like a big address book). The dns server tells you the ip of the url (for google it's 216.239.51.99). Without knowing the ip you (or your pc) wouldn't know whereabouts in the world the site was hosted on and so wouldn't be able to find it. DNS timeouts are where the dns server doesn't (for whatever reason) tell you the ip, so you can't go to the site.
Erm, I think this explanation is right, someone correct me if it's not.
LOL
Sorry, perhaps I should have been clearer and saved you a (quite good) explanation. I know what dns is (rather well in fact). I was trying to find out what problem they were experiencing, that they believed was a dns timeout. It is very rare for a dns request to timeout, and since most people don't understand dns they attribute other faults to "dns timeouts". A bit like many people blame the "proxy" server for problems that arn't actually proxy related. :)
@ Dan-
the traceroutes that you have posted show nothing about dns problems- every hop except for one resolved.
the one where you say it hung for 22seconds (195.66.226.185) doesn't have a domain name associated with it, so it is usual for there to be a pause while this is discovered.
The traceroutes seem to indicate packet loss problems, not dns problems- and pages loading slowly/ with bits missing would tie in with this.
A traceroute is not a good way of testing packet loss because of the way it runs. try pinging a host over a long period instead- try this at a command prompt:
ping 212.58.224.121 -n 100
and then post back the summary statistics. If you see any packet loss, try:
pathping 212.58.224.121 -n
and post back the results from that too.
@ Viras- PM me the mac address of your modem and i'll have a look at what is going on with your connection tomorrow.
@ Dan-
the traceroutes that you have posted show nothing about dns problems- every hop except for one resolved.
the one where you say it hung for 22seconds (195.66.226.185) doesn't have a domain name associated with it, so it is usual for there to be a pause while this is discovered.
Maybe I shouldn't have mentioned DNS in the topic. I wasn't sure what the problem was and that was just me grasping at straws.
I'll try the packet loss thing next time it goes wrong. So that's probably tomorrow then. :rolleyes:
JohnHorb
27-11-2004, 09:01
@ Viras- PM me the mac address of your modem and i'll have a look at what is going on with your connection tomorrow.Viras - as a newcomer, you may not be aware, but MB does work for NTL and it's OK to PM him this info (but don't post it on the forum). Hopefully a mod will come along and confirm this.
What do you mean by a "DNS timeout" ? The likes of:
> www.metafilter.com (http://www.metafilter.com)
Server: cache1.ntli.net
Address: 194.168.4.100
DNS request timed out.
timeout was 10 seconds.
DNS request timed out.
timeout was 10 seconds.
*** Request to cache1.ntli.net timed-out
Happening for a range of different sites - although possibly more for those with DNS hosted in the US.
My broswing was being a tad sluggish, so I just changed to a Manchester webcache and things seem to be flying now! If it doesn't stuff up again then it looks like it might have been the webcache.
Furthermore I'll add that whenever I turn off the proxy webcache I'm using, my default is ALWAYS leed-cache-9.server.ntli.net. Have ntl not heard of distributing the users across the different caches to spread the load?
Furthermore I'll add that whenever I turn off the proxy webcache I'm using, my default is ALWAYS leed-cache-9.server.ntli.net. Have ntl not heard of distributing the users across the different caches to spread the load?The load-spreading within the cluster is done by destination URL, not by user. So if you always use the same test site for identifying your proxy, you will always get the same answer. Each member of the cluster has its own little bit if the internet to cache, and your connection will utilise all members of the cluster according to the URL sought. It's more efficient that way.
The load-spreading within the cluster is done by destination URL, not by user. So if you always use the same test site for identifying your proxy, you will always get the same answer. Each member of the cluster has its own little bit if the internet to cache, and your connection will utilise all members of the cluster according to the URL sought. It's more efficient that way.
Absolutely! if the users of the same site were spread across all the caches, every cache would have to fetch a copy.
As for DNS timeout, I've seen my firewall catch attempts to issue ICMP destination unreachable, when the reply finally arrives too late to be any use.
If there's a way to tune this behaviour (in Win98SE), I've not found it yet.
What beats me, is that the address of NTL's email server (I might try plugging the ip address in directly) seems to be a victim as often as any remote address.
One thing which can disrupt DNS, is excessive load from firewall reverse DNS lookups (my firewall is set NOT to R-DNS every damn ping!, but many are).
That can magnify the normal DNS load by a huge margin.
One thing which can disrupt DNS, is excessive load from firewall reverse DNS lookups (my firewall is set NOT to R-DNS every damn ping!, but many are).
That can magnify the normal DNS load by a huge margin.Would this impinge on the network in general or my own PC ? The reason I ask is that I have a small problem that I suspect is DNS related.
My AV software, Command CSAV, from Authentium is set to auto update deffiles but I also receive instant notification via e-mail whenever new deffiles are posted, ( three or four times each day recently ). If I receive an e-mail notification I will always open my AV program to use the manual update even before auto update has kicked in. Sometimes manual update tells me that no new files are available, I put this down to DNS not yet updated and allow auto update to do its thing or try later. However over the past 2 days I have had several e-mail notifications but cannot update manually or automatically.
This morning as an experiment I disabled my Ntl BB and fired up my Zen dial up account and was instantly able to download deffiles that had been posted only a short time earlier.
The DNS should not be changing, though if it's the "slow DNS" problem, repeating the action after a few seconds, by which time the DNS has fetched the required record, should succeed - another alternative is to switch to an outside DNS, or for sites that rarely change address, stick the name/number in the hosts file.
http://www.analogx.com/contents/download/network/fc.htm
If nothing else in your system caches DNS (Windows does, but to a very limited degree), then this may help your performance. The first lookup will still be slow, but it'll slice some delay off so long as it remains in the cache.
The firewall issue is basically the problem that if a firewall does R-DNS every suspicious packet (and some DO), then it creates an additional (number of firewall users active) X (number of junk packets they get) load on the DNS server - if many firewalls are doing this, the load could considerably exceed the normal user load, since DNS is normally used only once at connection initiation, and even if no other cache is present, it should not be required again while browsing the same site - if you look at 100 forum posts, you will not be making 100 DNS requests.
vBulletin® v3.8.11, Copyright ©2000-2024, vBulletin Solutions Inc.