NTLs DNS ...

[poolking]

Is the browsing back to normal on the normal DNS?

[Dooby]

Originally Posted by handyman

try here

Seems there was some sort of attack on zonealarm aswell.

that suggests a DoS on some DNS servers, targetting the zone labs domain...interesting

seems that we may have a case of lots of **** hitting the fan at the same time...

unless of course the cable break turns out to be sabotage as well...

[KraGorn]

Originally Posted by Dooby

if all dns's were affected, how come i had an uninterupted nights browsing using different DNS?

Quite .. had it not been for DNS lookups failing I'd not have known there was a problem.

If it adds anything useful to the discussion, I had slooooow browsing (rapidly decaying into non-existent) until I switched off the NTL proxy specified in my settings. I have been using two non-ntl specified DNS for some weeks and I did nothing to alter those. Simple switching off my specified proxy returned me to speedy browsing.

[downquark1]

Originally Posted by handyman

try here

Seems there was some sort of attack on zonealarm aswell.

Why would attacks on zone alarm causes these problems?

Unless there are so mny attacks they are clogging up the link

[cliveb]

Originally Posted by Dooby

you will use NTLs DNS every time your browser needs to lookup a domain address ( assuming of course you are connected via ntl and havent overriden the dns settings )

I obviously didn't make myself clear. When I stated "I don't use NTL's DNS servers. The only time an NTL DNS should affect me is when one of their web proxies looks up a name", I was trying to point out that my DNS settings are explicitly set to non-NTL ones. I *HAVE* overridden the NTL DNS settings. So, when my browser (or any other application) looks up a name, it will go to the non-NTL DNS servers (and jolly reliable they are, too).

It's only when the browser makes a request on port 80 and NTL's tranparent proxy intercepts it that the trouble begins. The NTL web proxy appears to make a reverse-DNS lookup on the IP address, and of course it will use NTL's (sometimes non-functioning) DNS servers. There is nothing I can do to prevent this, other than to explicitly set up a non-NTL web proxy that runs on a port other than 80. And when I did so late last night (using a BT Openworld proxy that had been left open to non-BT users - probably inadvertantly), browsing sprang back to life.

Or maybe I've completely misunderstood how NTL's proxies work. I am only concluding that they do a reverse-DNS lookup based on the symptoms. It's possible that it was coincidence that everything started working at the same time I switched to the non-NTL proxy. What I'd really like to find out is exactly how NTL's proxies are set up.

[Dooby]

ah, ok, sorry cliveb, my mistake, i understand what you are getting at now..
what you said about reverse dns lookups would seem to fit with what towny said

[Dooby]

Originally Posted by downquark1

Why would attacks on zone alarm causes these problems?

Unless there are so mny attacks they are clogging up the link

because they arent attacks on zonealarm as such, they are attacks on DNS servers targeted at the lookup for www.zonealarm.com ( or that was my understanding )
essentially loads of requests to lookup the ip of www.zonealarm.com ( well thats one way of looking at it )

the side effect is that all dns lookups are slow or fail ( cos the dns server is getting so many hits )

*edit actually, thats ********, I missread the article*

Originally Posted by cliveb

Or maybe I've completely misunderstood how NTL's proxies work. I am only concluding that they do a reverse-DNS lookup based on the symptoms. It's possible that it was coincidence that everything started working at the same time I switched to the non-NTL proxy. What I'd really like to find out is exactly how NTL's proxies are set up.

Nothing is a simple as it first looks;

The Proxy servers don't do reverse lookups, very little would work if they relied on that system as a large number of website IP's don't have a reverse lookup available (non of mine do). Many websites share an IP as well.

When you request a page, your pc does a DNS lookup and sends the request to the identified IP. The proxy intercepts this request [on port 80] and checks the http headers for the host & page you requested. If it can supply this from its cache then it will, otherwise it will request the page itself to then pass it onto you. This will involve it doing a DNS lookup using the DNS servers it is set to use (which would presumably be NTL's).

If NTL's DNS is broken and you are using your own, you will be able to request & browse pages that the proxy has cached. If the proxy does not have them cached then it would not be able to request them for you because of its lack of DNS. You would not be able to access those pages.

However, if NTL's DNS were ok, but links to the US were down, you could still have a problem, even for web sites hosted in the UK (even with .co.uk domain names) if the domains master name servers are based in the US (like someone using zoneedit or register.com).

This is becuase if the entry for www.yourdomain.co.uk has expired from the local DNS servers cache then it has to be looked up again from the master name server [in the US]. If this cannot be done due to a link failure then you would not be able to access the site, you would get a DNS lookup failure even though the site is fine, uk based and NTL's DNS servers are fine.

A domains DNS record could also have expired on NTL's DNS servers but not the DNS servers you are using which would make the situation look even more strange (http to the site could fail, but https/ftp etc would work).

This will have been some of the problems last night, making DNS look broken, and some sites apparently working [for some people] and others not - the failed link was still the root of the problem.

[Jonboy]

blimey one night of no net access and a cry for refund
get a life i am a net addict but even i managed to find something else to do :p

[cliveb]

Originally Posted by pem

When you request a page, your pc does a DNS lookup and sends the request to the identified IP. The proxy intercepts this request [on port 80] and checks the http headers for the host & page you requested. If it can supply this from its cache then it will, otherwise it will request the page itself to then pass it onto you. This will involve it doing a DNS lookup using the DNS servers it is set to use (which would presumably be NTL's).

Let me make sure I've got this right....

When my browser is set up without an explicit proxy and I request, say, "www.bbc.co.uk", it is my understanding that my browser does a DNS lookup on that name and receives an IP address in reply. Then my browser attempts to connect to that IP address on port 80, at which point NTL's transparent proxy intercepts it. Now, at this stage, all the connections are being done at the IP address level, so why does the proxy have to do a DNS lookup?

You say that the proxy checks the http headers: am I to understand that in those headers will be the host name "www.bbc.co.uk", and it is this which causes the proxy to do a DNS lookup (if the page is not in its cache)? Seems a bit strange: why not just use the IP address in the original request that was intercepted, thus saving an unnecessary DNS lookup? (It would be a bit ironic if the answer is because NTL don't trust others' DNS servers :-)

[Dooby]

http://212.250.5.117/lookup/default.asp

DNS - affecting all internet packages (RESOLVED)

so are we now to take it that there WAS a problem with NTLs own DNS servers, and it WASNT the fact that there was a transatlantic cable break?
if so, my original comment stands, how did BOTH DNS ( primary and secondary ) fail together...


*edit, ah, maybe it is related to the "Planned Maintenance w/c 24/11/03"*

[threadbare]

Originally Posted by Dooby

http://212.250.5.117/lookup/default.asp

DNS - affecting all internet packages (RESOLVED)

so are we now to take it that there WAS a problem with NTLs own DNS servers, and it WASNT the fact that there was a transatlantic cable break?
if so, my original comment stands, how did BOTH DNS ( primary and secondary ) fail together...


*edit, ah, maybe it is related to the "Planned Maintenance w/c 24/11/03"*

The cable outage line was changed from DNS issues to "major outage", which i presume means that it appeared to be a DNS problem - it certainly appeared that way to me - and then, when it became apparant that it wasn't, they changed the message on the telephone line, but obviously not on the server status page.

[Dooby]

Originally Posted by threadbare

The cable outage line was changed from DNS issues to "major outage", which i presume means that it appeared to be a DNS problem - it certainly appeared that way to me - and then, when it became apparant that it wasn't, they changed the message on the telephone line, but obviously not on the server status page.

hmm, i still think there seems to be a tendency to blame this cable break for things that it wasnt to blame for... there WAS something f*cked up with NTLs DNS ( whether it was their fault or not ) as using a different set of DNS solved all the connection problems I was having...

[downquark1]

Originally Posted by Dooby

hmm, i still think there seems to be a tendency to blame this cable break for things that it wasnt to blame for... there WAS something f*cked up with NTLs DNS ( whether it was their fault or not ) as using a different set of DNS solved all the connection problems I was having...

Same here, but I did have some problems getting armerican sites earlier that day (on a non-ntl connection)