Norton DNS problem?

I did register with then a while back but never used them. Appeared to be to much of a hassle to use.

I created a "honeypot" server on my router. Anything with a malformed or unresolved IP address gets routed there, times out, and dies. This "polices" my ISP server connections.

Bottom line of this episode? Just another example of you can't trust anyone or anything when it comes to the Internet.

 

Very interesting.

I just tried the OpenDNS servers and guess what? The same 165.254.27.xxx connections appeared. The firewall block rule is still in place.

I am not totally surprised by this since I somewhat suspected NortonDNS was tied into OpenDNS.

 

Anyone interested in this topic should check out the page on Gibson Research site: http://www.grc.com/dns/configuring.htm. It is an eye opener to use of "supposedly" safe public DNS servers.

I just ran the "DNS Spoofing" test at the GRC site. Below are my test results. Since they are excellent across the board, I will stick with my ISP servers.

Query Source Port Analysis (worst case)

Max Entropy: 15.98
Excellent

Dir Bias: 1.82%
Excellent

Lost Entropy: 0.06
Excellent

Stuck Bits: 0
Excellent


Query Transaction ID Analysis (worst case)

Max Entropy: 16
Excellent

Dir Bias: 0.34%
Excellent

Lost Entropy: 0.05
Excellent

Stuck Bits: 0
Excellent

 

Itman:

If you click the link from Symantec forums at the beginning of this thread, the poster who first found this has elaborated on what he thinks is occurring. It's a theory similar to yours, ie., IE cert validations. But I'm not sure it is the whole story.

I'm decidedly *not* using ISP dns.

 

Hey, I know that guy. It's me

Per the GRC link I posted previously, below describes my setup. I have a DNS server on my router which does the IP connection. As long as your router doesn't get hacked(my has been on a couple of instances), it gives you a pretty secure connection.

In the case of having received the router's own private LAN IP for DNS resolution, machines on the LAN behind the router will send their DNS queries to the router, believing it to be a DNS resolver when, in fact, the router operates as a “proxy” for the actual public DNS resolvers. The router forwards any received DNS queries to the actual DNS resolvers on the public Internet and returns their results to the machine that originally issued the DNS query.

BTW - don't waste your time with the Norton forum. A bunch of trolls that will never give you a answer to anything without a hard time.

 

This problem has returned intermitently even with --
1) reinstall
2) switching to different DNS provider(s)

It came back after MS updates on the new install. It definitely involves the WinHTTP Web Proxy Auto Discovery Service. When I disabled it the problem has stoppped (for now). This involved connections to windows update to 165.254.119.xxx and 165.254.27.xxx -- really 165.254.0.0/16 -- which then also serves up advertising connections and etags from the very same IP during that session. The Windows updates understandably result in packets returned that indicate Http 404 "the site you are looking for may have moved" message, but only in the packets. No messages from Windows update indicating that anything had failed.

This seems to be advertising malware infection of the winhttp service or at worst, malicious web tracking proxy that hijacks your Win updates connection so that one does not get the updates and additionally one gets followed around and served up what may be bogus sites and/or etag tracking.

EDit: Spoke too soon. Turning off Winhttp svc made no difference. Still struggling with this. Going to try adblock.

 

That service is stopped on my WIN 7. Default startup mode is manual.

I believe that service is only used if you are using a proxy web server. If it is started on your PC, you might have a "hidden" proxy server which means you have possible malware issues.

 

I think the service attempts to *find* a web proxy using Web Proxy Autodiscovery Protocol (WPAD). Which tries a sequence of steps, using DHCP and also DNS, to try to locate a Proxy Auto Config (PAC) file. Which contains a javascript function that can identify the appropriate proxy for a given URL. Come to think of it, people have done ad blocking that way and I may have to refresh my memory on that approach.

Similar functionality is built into web browsers too. Look at settings for how they connect to the Internet.

For most individuals I think the correct approach is to disable such functionality to assure that a PAC file isn't inadvertently retrieved from someone else's server.

Overlooking any caching that might be involved, the WPAD network requests should be visible and if you take the time to learn the protocol and study the network traffic you could follow what is being attempted and what if anything worked. Edit: You could also manually duplicate at least some of its steps to see what the responses would be. For example, performing the DNS queries that WPAD would do.

 

Have you considered adding Fanboy's Adblock and Tracking Protection add-ons to your browser?