posted
I'm getting a lot of these DNS lookup error the last week or so.
Tonight I can't get to my Hot Mail account. Even after trying a refresh several times. That will work on some sites.
On the Turbo Teardown page their is this. "Turbo Page Advanced Configuration is disabled"
-------------------- Larry 99 34Q Discovery & 08 HHR LT2 Banks Powerpack F1 | D3 3.8.9 | HN7000S | 117/1070 |Hardwired through 8 Port Switch with WRT54 |Trav'ler Slimline SWM |Wilson SOHO Click here to see where I am Posts: 1151 | From: Homestead, FL | Registered: Aug 2003
| IP: Logged |
posted
The DNS Lookup Error messages have been reported numerous times to HughesNet, but nothing seems to have been done to track down the problem. The standard answer is to disable the turbo page, but that's not a suitable solution. You can try changing the turbo page and see if it helps.
-------------------- -- Ned -- Join us at www.rvforum.net Have you seen Rolling Stock? http://www.sashasoft.com D-Link DIR-655| Windows 7 Home Premium 64 bit Posts: 731 | From: On the road | Registered: May 2003
| IP: Logged |
posted
Hello, all Just came to this site to see what I might learn about these annoying DNS lookup errors. I called Hughes and went through the troubleshooting gauntlet with a very nice person from India. When she couldn't help me, she gave me a phone number to call for the Tier 2 help team. One thing led to another and I got a teir-4 technician. The only advice he could give me was to change my network's preferred DNS server address to 8.8.8.8 and Alt DNS to 8.8.4.4. Didn't change anything. I'd hoped someone here at DUG would have an answer.
-------------------- Ron Daves - 1997 Trek. HN7000S dish on self built quadripod-very stable. Posts: 15 | From: Rver | Registered: May 2010
| IP: Logged |
posted
Using the Google DNS servers (8.8.8.8 and 8.8.4.4) doesn't help because the network intercepts all DNS requests over the standard DNS ports and redirects them to the Hughes servers, which often aren't working properly.
One thing to try is to install the OpenDNS DNSCrypt software (http://www.opendns.com/technology/dnscrypt). That uses HTTPS to make DNS requests from the OpenDNS servers. The primary purpose is to hide your DNS requests from anyone on your network (including your ISP). The bonus is that Hughes won't see them, so they can't intercept them. DNS responses will be slower than from Hughes, but they should get through reliably.
joe
-------------------- Cradlepoint MBR95, Sierra USB-250U (Sprint WiMax) 2008 Newmar King Aire 4562, 2012 Jeep Liberty Limited Jet We're here! Posts: 683 | Registered: Nov 2007
| IP: Logged |
posted
DNSCrypt does not stop the DNS Lookup Errors. I've tried. I've also tried several different DNS servers, including OpenDNS and none of them are immune from the errors. There are a lot of HN users complaining about the problem but nothing seems to be done about it.
When the HN proxy assembles the page it's not using our DNS servers, it's using whatever servers the proxy uses and we have no control over them.
I haven't kept track but the DNS Lookup Errors are on http pages only, I believe, as those are handled by the proxy. https pages would not be and should not be subject to the problem. I'll have to watch more carefully as at least half of my web pages are using https.
-------------------- -- Ned -- Join us at www.rvforum.net Have you seen Rolling Stock? http://www.sashasoft.com D-Link DIR-655| Windows 7 Home Premium 64 bit Posts: 731 | From: On the road | Registered: May 2003
| IP: Logged |
posted
(I start off assuming a configuration problem, but further down I question my logic) Something is wrong, Ned. Sequence:
Browser asks for www.datastormusers.com DNS Server returns 63.161.122.77 Browser asks for content from 63.161.122.77
Scenario A: Browser's DNS request is seen by Hughes and it attempts a lookup but has a failure.
Scenario B: Browser's DNS request is made via SSL, which Hughes can't see, so lookup returns OK.
Either way, when the browser requests the content from the IP, there is no DNS server involved, unless Hughes is trying a reverse lookup. The latter should not be done, because multiple sites can share a single IP.
So, I conclude that DNSCrypt should work, and there must be a configuration problem.
Easy test: compile IPs for your regular non-SSL browsing locations. Then try going there by IP.
As I was typing this, I realized how/why the problem probably occurs. Within a high number of commercial pages are links to many, many other hosts and domains. Those would be requested by the proxy, not by your browser.
I'm on DSL. I mess around with my DNS settings fairly often because of problems. At times I use AT&T's defaults, and at the moment I'm using 8.8.8.8 as the primary and my own server (which I'm on a constant hardware VPN to) as secondary.
I see large numbers of failures. Just now I connected to Marketwatch. The request hung on a "looking up i.marketwatch.com" and eventually displayed the page for me with no style sheet and no images.
This was quite common. But what if the Hughes server, in its infinite wisdom, just returns an overall error?
quote:Originally posted by Ned: When the HN proxy assembles the page it's not using our DNS servers, it's using whatever servers the proxy uses and we have no control over them.
What does this mean? The proxy can't "assemble" the page. Only the browser can do that. What the proxy can (and should) do is pre-fetch the pages (and maybe send them to the modem) so that client doesn't wait as long for them. But the subsequent DNS lookups are still going to go through the DNSCrypt pipe.
Hmm. Maybe the Hughes system is more insidious than I thought. Does it actually hold up the original page fetch, fetch the other content, and INSERT the contents into the original page content? That seems technically very difficult and fraught with pitfalls.
Pre-fetching in the proxy is likely. Content assembly in the proxy not so much. But I've never actually used a Hughes system, so I'm not positive.
joe
-------------------- Cradlepoint MBR95, Sierra USB-250U (Sprint WiMax) 2008 Newmar King Aire 4562, 2012 Jeep Liberty Limited Jet We're here! Posts: 683 | Registered: Nov 2007
| IP: Logged |
posted
As I've always understood it, the Hughes Proxy is an aggregation proxy - it tries to aggregate the whole package and send it on to the modem, where it is decompressed and fed to the requesting browser.
When an element can't be received after a short time-out it is left out and is sent along later. If a similar timeout isn't used when the problem is a DNS lookup for the element then it would explain the current problem.
posted
That's how I understand it too. In order to do the aggregation, the proxy server must do DNS lookups to fetch the various pieces of the page and we can't control that. The only DNS lookup that our browser does is the initial one for the page domain.
-------------------- -- Ned -- Join us at www.rvforum.net Have you seen Rolling Stock? http://www.sashasoft.com D-Link DIR-655| Windows 7 Home Premium 64 bit Posts: 731 | From: On the road | Registered: May 2003
| IP: Logged |
posted
What I don't get is that if the proxy is doing the aggregation fetches, and therefor the lookups, how is the client computer at the other end of the sat connection getting a DNS error?
joe
-------------------- Cradlepoint MBR95, Sierra USB-250U (Sprint WiMax) 2008 Newmar King Aire 4562, 2012 Jeep Liberty Limited Jet We're here! Posts: 683 | Registered: Nov 2007
| IP: Logged |
posted
IF (and it is still an IF) we are correct that the error is occurring on some page element, the actual problem would be that the proxy is giving up and returning an error code. See this definition in the http status codes: ------------- 10.5.5 504 Gateway Timeout
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.
Note: Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out. ---------------
posted
It would be preferable for the proxy to just insert a placeholder for any element that it can't retrieve, but HughesNet doesn't work that way and apparently just drops the whole page and sends the error.
I have not seen any errors this morning on any https links, only http, including some http links from an https page, but never on the https links themselves. I suppose the next test would be to disable the HN proxy completely and see if the errors go away, at the expense of slowing down http pages.
-------------------- -- Ned -- Join us at www.rvforum.net Have you seen Rolling Stock? http://www.sashasoft.com D-Link DIR-655| Windows 7 Home Premium 64 bit Posts: 731 | From: On the road | Registered: May 2003
| IP: Logged |
posted
When it comes to retrieval of an element I think the proxy will return without one. At least that has been my experience. I'm guessing the problem is DNS failure on the page element, rather than the element itself.
I agree it should display without the element, either way.
posted
I agree that returning an error for any fetch that was not initiated by the end user is a design error. If it can't fetch an element, for any reason, it should just ignore it and keep going. The client will either try the fetch again or render without it.
joe
-------------------- Cradlepoint MBR95, Sierra USB-250U (Sprint WiMax) 2008 Newmar King Aire 4562, 2012 Jeep Liberty Limited Jet We're here! Posts: 683 | Registered: Nov 2007
| IP: Logged |
UBBFriend: Email this page to someone!
Printer-friendly view of this topic
![[Mad]](mad.gif)
