Norton DNS problem?

[learningcurve]

Has anyone here noticed while using Norton DNS, that *many* of their connections are funneled through edgesuite.net ips? Range 165.254.27.0-255. Newspaper sites, shopping sites, etc. Noticed a significant number of these ips on 10/1 and today, 10/2. Googled the problem and this lone post on Norton site hit on my issue exactly.

http://community.norton.com/t5/Other...NS/td-p/815004

The solution is to change to another DNS provider. This did work for me. Tried to register w/ Norton site to reply to OP but still awaiting verification. OP found this 9/29.

[Breakfastofchumps]

Thanks for bringing this up I'll be watching this thread with interest.

[TheWindBringeth]

I don't use Norton DNS, but for fun I performed about a dozen queries for shopping sites using server 198.153.192.50 and all of the answers matched those from my ISP's server.

That Norton server answered with 198.153.192.3 for unknown hosts, and when I rigged up an HTTP request to that unknown host on 198.153.192.3 I got a 302 redirect to an -http://www.ask.com/... page delivered by an Akamai EdgeSuite server near me.

[learningcurve]

No longer think this is Norton DNS (have never had an issue with it before). Sorry Norton!

Some sort of tagging process or super tracking cookie? I changed DNS servers to OpenDns and the problem came back --after I went to a specific site. I will post more when I restart my browsing session to test something out. Using sandboxie, KIS and HTMPro and no tracking cookies have been found. I scour for temp files before rebooting. Hoping someone else has seen this... Will check router also.

[learningcurve]

This seems to be Etag-ing on steroids. It was unusual to see in wireshark, not something I was used to seeing to the extent I did. I still see it using OpenDns, *but* it is more limited, usually after visiting a popular blog and clicking on news links. Each link clicked activates edgesuite.net ip 165.254.27.xxx (thousands of connections?) with an etag and some of the site's contents. So more links I click more 156.254.27.xx connections I see.

However, instances of Etagging -- 156.254.27.xxx -- seemed substantially higher using Norton DNS? With Norton DNS it seemed as if one edgesuite ip was providing content and Etagging everywhere I surfed-- unusual if not alarming for seemingly disparate websites, especially for news.

Not very knowledgeable in this area I'm afraid, just noticed connections out of ordinary. I use noscript, request policy, https everywhere, but no match for etagging I guess. Why I am seeing this all of the sudden? Perhaps KIS network protection components are not working well?

[TheWindBringeth]

Originally Posted by learningcurve

Each link clicked activates edgesuite.net ip 165.254.27.xxx (thousands of connections?) with an etag and some of the site's contents. So more links I click more 156.254.27.xx connections I see.

ETags may or may not be a problem depending on how they are being used. The more important question would be whether or not the server connections and requests/responses are appropriate and as desired. Wireshark won't show you the requests/responses carried over SSL so where that is involved you'll have to gut check the server connections (or use another approach). If you click on a link to, or an html page pulls an image from, https://www.example.com/car.jpg then you would expect to see your browser establish a secure connection with the IP Address for hostname www.example.com.

Due to the way DNS and Wireshark work, the hostname displayed by Wireshark in the Source and Destination fields may not match the hostname in URLs. A hostname such as www.example.com may be aliased to www.example.com.edgesuite.net and/or a152.dscb.akamai.net because Akamai is being used as a content delivery system.

Inside HTTP Requests there is a Host: header which contains the same hostname that appears in the URL of the resource that is being requested. You can display that header in a custom column: http://jacob.hoffman-andrews.com/REA...-to-wireshark/. If you do that and temporarily simplify the view via display filter (Filter: dns or http) you'll get a feel for the hostnames issue.

[learningcurve]

Thanks for the link on wireshark, TheWindBringeth. The investigation into what is going on with computer is evolving.

Long story, short: Last night, discovered Kaspersky process, avp.exe, was opening connections to the suspect ip range: 165.254.27.xxx. Posted on Kaspersky forum. No answers.

Then today, started to look around, went into sandboxie via Explorer, and found files. I always delete the defaultbox, so it was evidently not emptying completely. Then went into safemode and found 1mb *still* in sandbox. Deleted. Thereafter no more connections to suspect ips. Defaultbox could have been incompletely deleting for a few days (as long as symptoms have occurred). The Sandbox allows direct access to some Kaspersky components. If interested complete rundown is here: --http://www.sandboxie.com/phpbb/viewtopic.php?t=13781 --

[learningcurve]

Originally Posted by TheWindBringeth

Inside HTTP Requests there is a Host: header which contains the same hostname that appears in the URL of the resource that is being requested. You can display that header in a custom column: http://jacob.hoffman-andrews.com/REA...-to-wireshark/. If you do that and temporarily simplify the view via display filter (Filter: dns or http) you'll get a feel for the hostnames issue.

TheWindBringeth: per the nice link you posted, I added host column. The kaspersky (avp.exe) initiated connections to the suspect ips 165.254.27.97 and 112 show host as windows update.

This *would* be unquestioned on my part *except* this ip range has so many unintiated connections with etags following me around the net. Maybe it's microsoft, but Robtex says NTT America, if it's MS it usually says so. Usually update server is 65.xxx.xxx.xxx.

Snippets from wireshark:

467 2012-10-03 23:36:34.019896000 192.168.1.xxx 165.254.27.112 HTTP 229 HEAD /v9/1/windowsupdate/redir/muv4wuredir.cab?1210040336 HTTP/1.1 49179 80 download.windowsupdate.com

277 2012-10-03 23:36:29.793857000 192.168.1.xxx 165.254.27.112 HTTP 228 GET /v9/1/windowsupdate/redir/muv4wuredir.cab?1210040336 HTTP/1.1 49179 80 download.windowsupdate.com


279 2012-10-03 23:36:29.856466000 192.168.1.xxx 165.254.27.97 HTTP 225 HEAD /v9/1/windowsupdate/redir/muv4wuredir.cab?1210040336 HTTP/1.1 49172 80 download.microsoft.com


The next ip looks like MS but is listed in Robtex as on blacklist:

285 2012-10-03 23:36:29.931565000 192.168.1.xxx 65.54.51.253 HTTP 227 HEAD /v9/1/windowsupdate/redir/muv4wuredir.cab?1210040336 HTTP/1.1 49174 80 www.update.microsoft.com

Robtex screenie is attachment.

I'm getting whiplash from this...

[TheWindBringeth]

The 65.54.51.253 IP Address for www.update.microsoft.com looks good to me.

www.update.microsoft.com@ns1.msft.net.:
www.update.microsoft.com. 3600 IN CNAME www.update.microsoft.com.nsatc.net.

www.update.microsoft.com.nsatc.net.@a.ns.nsatc.net.:
www.update.microsoft.com.nsatc.net. 300 IN A 65.54.51.253

www.update.microsoft.com.nsatc.net seems location dependent and load balanced. For example: http://just-dnslookup.com/index.php?...&s=dns+lookup!

Based on the Robtex info and a lookup, it appears that those who have control over the DNS records for englishclub.2288.org (malware-ish looking) have configured its IP Address to be the same 65.54.51.253. I don't know what is up with that, but maybe that contributed to the blacklist entry(?).

Based on some things I've seen, and you seemed to confirm it earlier, the 165.254.27.97 and 165.254.27.112 IP Addresses are associated with EdgeSuite machines serving things for download.microsoft.com and download.windowsupdate.com. I wasn't able to get those IP Addresses during test lookups though, which might be explained by location/load balancing or Akamai changes.

I don't know why you saw all the things you did. Something you said earlier did indeed make me wonder if at least some of them were related to malicious URL checking or other cloud AV lookups. Which theoretically could be done on a selective basis (I don't know your software) and so you might want to hit safe but less well known URLs while trying to test that. Obviously be on the lookout for HTTP or HTTPS, well known port or other, etc. Hopefully if you keep a close eye on things you will be able to explain everything you see.

PS: Just a crazy thought, but one thing you might check is your Microsoft/Windows Update History just to see if it reflects some kind of repetitive problem automatically updating or something.

[itman]

I also use NortonDNS.

Try to block 165.254.27.0 - 165.254.27.255 with your firewall. I tried with the WIN 7 firewall to block both inbound and outbound to that address range. Guess what? It went right past the firewall!

I have found out the connections are originating from LLMNR i.e TCP/UDP port 5355 which is supposed to be restricted to DNS resolution on your LAN only. I have seen WIN 7 LLMNR use dnscache to connect to Internet via TCP and no one seems to know why.

This tells me WIN 7 tunneling is involved which bypasses all firewalls. I have Teredo and IP6 to IP4 tunnel services disabled. That leaves IPHTTPS tunneling. I have IPHTTPS WIN 7 firewall rules disabled. I believe WIN 7 will internally ignore it's firewall when it comes to certain IPHTTPS traffic.

I suspect these 165.254.27 connections are IE9 web site cert. validations using IPHTTPS.

[learningcurve]

Originally Posted by TheWindBringeth

The 65.54.51.253 IP Address for www.update.microsoft.com looks good to me.

www.update.microsoft.com.nsatc.net seems location dependent and load balanced. For example: http://just-dnslookup.com/index.php?...&s=dns+lookup!

Based on some things I've seen, and you seemed to confirm it earlier, the 165.254.27.97 and 165.254.27.112 IP Addresses are associated with EdgeSuite machines serving things for download.microsoft.com and download.windowsupdate.com. I wasn't able to get those IP Addresses during test lookups though, which might be explained by location/load balancing or Akamai changes.

I don't know why you saw all the things you did. Something you said earlier did indeed make me wonder if at least some of them were related to malicious URL checking or other cloud AV lookups....

The WindBringeth:
Thanks for confirming that MS uses other non-MS servers for downloads. I could not find a confirmation that this was normal -- up to now never really saw anything to scrutinize with MS connections.

The problem is just weird. First, many, many 165.254.27.xxx connections while surfing mainly news sites (using Norton DNS). Then later when I change to Open DNS and make sure Kaspersky web components are working (Anti-banner was *not*), the connections to 165.254.27.xxx were still occurring but now from MS update check and sporadically while surfing, but less than before.

As far as the malware-ish behavior you thought I was describing, here is an example of Oct 1 of *many* connections (these are just some GETs) to 165.254.27.xxx using Norton DNS:

4818 2012-10-01 15:32:50.657644000 192.168.1.xxx 165.254.27.73 HTTP 433 GET /images/2012/10/01/arts/01BOOK/01BOOK-thumbStandard.jpg HTTP/1.1 49453 80 graphics8.nytimes.com

6590 2012-10-01 15:37:45.747047000 192.168.1.xxx 165.254.27.83 HTTP 347 GET /images/misc/nytlogo379x64.gif HTTP/1.1 49633 80 i1.nyt.com

10331 2012-10-01 15:40:34.549025000 192.168.1.xxx 165.254.27.105 HTTP 511 GET /en/sites/france24.com.en/themes/france24/logo-en.png HTTP/1.1 49867 80 www.france24.com


13116 2012-10-01 15:42:19.836373000 192.168.1.xxx 165.254.27.99 HTTP 570 GET /news/article-2210522/html HTTP/1.1 50001 80 www.dailymail.co.uk

18615 2012-10-01 15:59:57.005769000 192.168.1.xxx 165.254.27.105 HTTP 473 GET /images/8a/82/cca55eaa467daf8f3bc9754f8bf5.gif HTTP/1.1 50300 80 i.thestar.com


29128 2012-10-01 17:31:39.818864000 192.168.1.xxx 165.254.27.74 HTTP 662 GET /public/resources/MWimages/MW-AT582_trader_MA_20120808125741.jpg HTTP/1.1 51034 80 s.marketwatch.com


32695 2012-10-01 17:34:50.099930000 192.168.1.xxx 165.254.27.113 HTTP 418 GET /css/utils.css HTTP/1.1 51245 80 www.newyorker.com

33388 2012-10-01 17:34:53.109656000 192.168.1.xxx 165.254.27.72 HTTP 371 GET /favicon.ico HTTP/1.1 51289 80 [b]www.washingtonpost.com/B]


Then after changing to Open DNS, connections appear to 165.254.27.xxx through MS Update *and* some news sites, 10/3 session:

213 2012-10-03 23:36:25.796752000 192.168.1.xxx 165.254.27.97 HTTP 225 HEAD /v9/1/windowsupdate/redir/muv4wuredir.cab?1210040336 HTTP/1.1 49172 80 download.microsoft.com

217 2012-10-03 23:36:25.828009000 192.168.1.xxx 165.254.27.97 HTTP 224 GET /v9/1/windowsupdate/redir/muv4wuredir.cab?1210040336 HTTP/1.1 49172 80 download.microsoft.com

218 2012-10-03 23:36:25.856695000 165.254.27.97 192.168.1.xxx HTTP/DL 1506 unknown (0x4 80 49172

219 2012-10-03 23:36:25.856787000 165.254.27.97 192.168.1.xxx HTTP 60 Continuation or non-HTTP traffic 80 49172

9752 2012-10-04 00:01:21.649387000 192.168.1.xxx 165.254.27.82 HTTP 340 GET /msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab?cb7937fee62294a4 HTTP/1.1 49439 80 ctldl.windowsupdate.com

17447 2012-10-04 00:31:06.866349000 192.168.1.xxx 165.254.27.82 HTTP 464 GET /preset.jpg HTTP/1.1 49909 80 mjcdn.motherjones.com


As of today upon connecting to the internet netstat indicated a connection to 165.254.27.104 as well as an MS update ip. So it still happening. There is less ETag-ing as far as I know. Is it possible that ETag-ing (ads) and MS update come from the same range of servers?

Thanks again TheWindBringeth for the feedback.

FYI: Posted a query at Kaspersky forum asking if this was a proxy/AV, was left unanswered for a few days, so I guess it's not KIS. Will post if they answer.

[learningcurve]

Originally Posted by itman

I also use NortonDNS.

Try to block 165.254.27.0 - 165.254.27.255 with your firewall. I tried with the WIN 7 firewall to block both inbound and outbound to that address range. Guess what? It went right past the firewall!

....This tells me WIN 7 tunneling is involved which bypasses all firewalls. I have Teredo and IP6 to IP4 tunnel services disabled. That leaves IPHTTPS tunneling. I have IPHTTPS WIN 7 firewall rules disabled. I believe WIN 7 will internally ignore it's firewall when it comes to certain IPHTTPS traffic.

I suspect these 165.254.27 connections are IE9 web site cert. validations using IPHTTPS.

Itman:

"I suspect these 165.254.27 connections are IE9 web site cert. validations using IPHTTPS."

I too have IPv6, 6 to 4 and teredo turned off. IPHTTPs I left on for possible use. All the connections to 165.254.27.xxx are HTTP/80. LLMNR is also turned off via Group Pol. Perhaps blocking port 5355 would work, but I see no 5355 port entries maybe because of KIS proxy. Then am I blocking useful MS services? MS making it harder to lock down Windows?

At first I did block the ip range 165.254.27.0-255 in KIS firewall. This resulted in not being able to connect to news sites (see previous post on surfing news sites and this IP range). But if I get what you're suggesting, I will try the firewall block to see if MS connects regardless.

So far it would seem that MS is using 165.254.27.xxx ip range for it's services and so are news sites for content and etag-ing. This seems weird, but I defer to you, I'm a newbie.

[itman]

LLMNR is also turned off via Group Pol. Perhaps blocking port 5355 would work, but I see no 5355 port entries maybe because of KIS proxy. Then am I blocking useful MS services? MS making it harder to lock down Windows?

MS is very tight lipped when it comes to LLMNR. Like I said, I have seen WIN 7 outbound TCP connections from it to the Internet. These are coming from svchost.exe - dnscache sevice and result in a normal outbound TCP port connection. And also like I said, I beleive these are IPHTTPS tunnel connections.

At first I did block the ip range 165.254.27.0-255 in KIS firewall. This resulted in not being able to connect to news sites (see previous post on Oct 1 surfing news sites and this IP range).

I do find this interesting since the WIN 7 firewall ignored my oubound block rule. Your blocked rule possibly worked I believe because they were un-tunneled connections by virtue of your disabling LLMNR via group policy?

Bottom line - 165.254.27 is Akami. MS and Akami are like "two peas in a pod." I really would not worry about those connections. The fact that you have verifed the connections route though MS Updates, actually a MS IP address range, this points to web site cert. update activity.

Then am I blocking useful MS services? MS making it harder to lock down Windows?

What I have seen is the cert. updates will occur but via un-tunneled connections. This can be assumed to be less secure since a connection could be hijacked. I have also yet to find a third party firewall that handled the WIN 7 tunnels properly which is why I am using the WIN 7 firewall.

A better one is how Norton is using the IPHHTPS tunnel for it's ccsvchost.exe connections. I have seen these connects using WIN 7 resource manager and TCPView shows zip.

[itman]

I am reversing myself.

This morning I boot and I see svchost.exe connections to 165.254.27. I start browsing and I see svchost.exe connections to 165.254.27.

So I dumped NortonDNS and went back to my ISP servers for the time being. I also did a flush/release/renew ipconfig routine to clear out any crap in the DNS cache.

Note that when browsing, I now see 24.143.196 which is RoadRunner via Akami versus the 165.254.27 NTT America connections. These I am not concerned about. It is svchost.exe connections I am concerned about. Sure looks to me that NortonDNS is uploading tracking info.

[TheWindBringeth]

Originally Posted by learningcurve

Is it possible that ETag-ing (ads) and MS update come from the same range of servers?

ETags can be enabled/disabled on any server. It's possible that one server, or set of servers, serving content for www.example.com will use ETags while others do not (due to oversight or choice). Whether the ETags are just being used for caching purposes or tracking purposes could also vary. Transparent proxies between you and the servers may or may not be involved as well. That's on top of DNS being used to steer things to different servers for purposes of balancing/optimizing things, DNS caching, etc. So there can be considerable variability.

[itman]

What I am seeing is connects to msecn from svchost.exe along with another Akami connection. They persist even when switched back to my ISP servers.

What I am wondering if this has anything to do with the Google tracking blocker add-on I installed from MS a while back. I will disable that for a while and see if these connections go away.

[learningcurve]

Do not know if this is related to IP prob or not.

All connections to 165.254.27.xxx have ceased starting yesterday 10/9. The caveat is that HTTP/80 stopped functioning. I can connect to HTTPS only. 60-70% HTTP/80 the packets are dropped (TCP retansmissions, dup ACKs) so no meaningful connections on port 80. Nothing was changed by me, but KIS seemed to lose some restore/reset features suddenly. Have tried usual fixes, reset adapter, reset ip/winsock, reset router, reset KIS firewall, then reinstall KIS. Tried Live CD -- so it's networking (router or adapter) that's somehow hosed.

Itman:
"This morning I boot and I see svchost.exe connections to 165.254.27."
Exactly what I was seeing. Was bit alarmed because I'd already seen this ip range following me around while surfing. And the connections did persist when I changed from Norton to OpenDNS, just less traffic.

The thought that Win 7 is tunneling but it's not readily apparent in connections is so beyond my limited understanding of networking. Why would Win 7 need to do this? If this is MS's efforts to address Google tracking (no addons here) -- well, wow.

The WindBringeth: Its probably tangential, but I checked update.log and there are errors updating IE9, I think, with the service WINHTTP svc (manual/enabled on my machine) being involved. Error codes (0x80190194, 80072ee7) happen no matter if WINHTTP is manual or automatic-enabled.

EDIT:
TheWindBringeth: Your mention of a transparent proxy is intriguing, I have never heard of it before. And it cannot be used on HTTPS -- only HTTP! Just now read that it could be implemented at hardware firewall (router) and maybe ISP? But if Itman is having this issue...

[learningcurve]

Originally Posted by TheWindBringeth

...Whether the ETags are just being used for caching purposes or tracking purposes could also vary. Transparent proxies between you and the servers may or may not be involved as well. That's on top of DNS being used to steer things to different servers for purposes of balancing/optimizing things, DNS caching, etc. So there can be considerable variability.

The WindBringeth: you are so right about the complexity and variability of all this. Your perspective shows your expertise. Would like to ask if a transparent proxy component on (probably [Cisco] router) could lose functionality from reset of the router? Then when attempts to access HTTP after the reset, the client browser receives "The connection has been reset" messages? All this has happened to me since yesterday. (Wireshark shows HTTP connections just too many packets dropped). If this were ISP level I would still have HTTP surfing, right? If at router level I would see what I've experienced after a router reset. (See above post #17. HTTPS is fine).

From Wiki on detecting transparent proxies: -https://en.wikipedia.org/wiki/Http_proxy-

By attempting to make a connection to an IP address at which there is known to be no server. The proxy will accept the connection and then attempt to proxy it on. When the proxy finds no server to accept the connection it may return an error message or simply close the connection to the client. This difference in behaviour is simple to detect. For example most web browsers will generate a browser created error page in the case where they cannot connect to an HTTP server but will return a different error in the case where the connection is accepted and then closed

Or am I barking up the wrong tree?

[itman]

Interesting -the winhttp service reference.

I use Svchost Analyzer by Nueber.com to check my svchost.exe instances. Everything checks out fine except for you know what -winhttp. Svchost Analyzer says winhttp.dll doesn't exist. So I search my HDD where WIN 7 is installed and it's there and where it's supposed to be. So what gives?

A bit more research and it appears both Zemana AntiLogger plus Norton Antivirus 2012 are injecting winhttp. Bottom line - both have set up hidden proxy servers. Makes sense since definitely NAV is monitoring web connections for malware. I suspect Zemana is using it to promote their SSL anti-logger technology.

I also suspect Kapersky is fooling with winhttp.dll also to support their web protection.

I also have not received anymore 165.254.27 svchost.exe connections today so I am hoping the MS add-on to block Google was the culprit. Will continue monitoring.

BTW - I downloaded this month's WIN 7 updates today prior to doing any surfing. So it is possible these patched this 165.254.27 activity? I very much beleive this activity was MS originated. Like I said above, most of the dial-outs to 165.242.27 were were preceded by a svchost.exe connection to msecn.

It is also possible a MS update server was hacked. Wouldn't be the first time that happened. Also MS uses Akamai servers extensively for MS updates.

[itman]

The dial-out to msecn just occured again with a subsequent dial-out to 204.183.124.127. This is Akamai again. PID of svchost.exe cross-referenced to LLMNR svchost.exe PID.

I think I know what these dial-outs are - Windows Experience. I ran into this when I tried to create outbound rules for the WIN 7 firewall. Try as I might. I could never stop a svchost.exe dial-out from always getting blocked. I opted out of WIN experience. Still these LLMNR dnscache connections persisted.

Bottom line - MS is uploading your usage and their is nothing you can do about it. The service used is a hidden one hence you will never be able to define a firewall rule for it other than block all outbound svchost.exe. Obviously that is not an option.

[learningcurve]

Originally Posted by itman

Bottom line - MS is uploading your usage and their is nothing you can do about it. The service used is a hidden one hence you will never be able to define a firewall rule for it other than block all outbound svchost.exe. Obviously that is not an option.

Your explanation sounds good. I'm glad there is a reason for the winhttp not working, all of this together was contributing to a conclusion of something nefarious -- if one can say that MS sending data out (I opted out of Experience also) is not considered nefarious. The data may be error reporting in my case. I think that while using Norton DNS the sus ip range 165.254.27.xxx serving *content* and etags, and then using OpenDNS with MS connecting to this ip range was too much coincidence, but plausible nonetheless. Kudos to you for finding a possible answer.

This may be unrelated but after a router reset I lost HTTP, can use HTTPS only. Do you have any suggestions about how to troubleshoot. Many TCP retransmission, dup ACKs, and never before seen RST and RST,ACKs in trace.

[TheWindBringeth]

Originally Posted by learningcurve

This may be unrelated but after a router reset I lost HTTP, can use HTTPS only. Do you have any suggestions about how to troubleshoot. Many TCP retransmission, dup ACKs, and never before seen RST and RST,ACKs in trace.

You would start by carefully checking out the configuration/operation of your router (and modem, if separate) using another computer if necessary. Once any problems there are sorted out, then you would focus on the computer you are having problems with. If you are totally without HTTP and need information on how to do that, you can use https://startpage.com/ and then in the search results click on View by Ixquick Proxy. You'll probably want to power cycle the router (and modem) during that process, and may even end up resetting the router again. At the point you are finalizing configuration settings, review *everything* but especially parental controls and any other feature that might mess with HTTP.

Don't get lost amongst unfamiliar trees.

[itman]

More info on 165.254.27.

This IP is definitely coming from NortonDNS. When I use my ISP's servers, I never see a connection in that IP range.

If I try to block 165.254.27.0 - 165.254.27.255 as an outbound connection in the WIN 7 firewall, I still get IE9 connections in that IP range.

Conclusion, either a tunnel connection is involved or a redirect is going on via NortonDNS.

Also another interesting development is that I saw ccsvchost.exe, NAV's realtime monitor, connectiing to the 165.254.27 range. This tells me that Symantec is uploading data. Ccsvchost.exe also bypasses the firewall by connecting through localhost.

So I have permanently dumped NortonDNS.

[fblais]

Thanks!
Did you try OpenDNS too?

[learningcurve]

Originally Posted by itman

More info on 165.254.27.

This IP is definitely coming from NortonDNS. When I use my ISP's servers, I never see a connection in that IP range.

If I try to block 165.254.27.0 - 165.254.27.255 as an outbound connection in the WIN 7 firewall, I still get IE9 connections in that IP range.

Conclusion, either a tunnel connection is involved or a redirect is going on via NortonDNS.

Also another interesting development is that I saw ccsvchost.exe, NAV's realtime monitor, connectiing to the 165.254.27 range. This tells me that Symantec is uploading data. Ccsvchost.exe also bypasses the firewall by connecting through localhost.

So I have permanently dumped NortonDNS.

Itman: So have I. Got my router fixed (The unrelated HTTP problem), and I am back up and using another DNS provider (Comodo). Now my traces look normal.