Hughesnet Community

DNS TTL rewrite

cancel
Showing results for 
Search instead for 
Did you mean: 
sozoridge
Sophomore

DNS TTL rewrite

https://community.hughesnet.com/t5/Tech-Support/Unable-to-load-Amazon-Problem-Upstream-From-Modem/td...

 

That thread is marked as resolved, but with no technical explanation.

 

Hughesnet had the bad habit of rewritting the TTL of all DNS lookups (regardless of what DNS server was queried) to a minimum value of 1200 (if I recall correctly), generally breaking the internet.  Amazon was the most visibly affected by this.

 

It would appear that with the resolution of the above thread, the TTL is no longer being rewritten.  Hopefully it is also being honored by the modem's DNS cache.

 

Can support confirm that the fix was to no longer rewrite DNS TTL on all queries?  My testing appears to confirm this, but as I was about to leave Hughesnet because of this fundamental protocol violation, I'd like to get a confirmation that it is indeed fixed.

 

It'd also be wonderful to have the option to turn off "DNS Acceleration", just as we have the option to turn off "Web Acceleration".

7 REPLIES 7
sozoridge
Sophomore

@Lizany chance for an answer to this?

Hi sozoridge,

 

I have reached out to our network engineering group to get some more detail on what happened. I will paste it here once they get back to me.

 

Thanks,

Amanda

Hi @Amanda,  I'm still looking for a response here.

 

However, I received a new ht2000w modem today, and am having continual DNS errors.  Once again, I find that all DNS queries are being rewritten, with the target DNS server completely ignored.  For example, I couldn't even get to this website until I reset the modem because of its broken DNS implementation.

 

For example using googles DNS server, a bogus result for this website was being returned, because the DNS query is never actually made to the google DNS server

 

$ dig @8.8.8.8 community.hughesnet.com

; <<>> DiG 9.11.2 <<>> @8.8.8.8 community.hughesnet.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60360
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;community.hughesnet.com.    IN    A

;; ANSWER SECTION:
community.hughesnet.com. 60    IN    CNAME    c.media-amazon.com.
c.media-amazon.com.    60    IN    A    13.33.253.147

;; Query time: 12 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Dec 01 17:17:20 PST 2017
;; MSG SIZE  rcvd: 89

 

To prove the point, I use a completely bogus DNS server IP which doesn't exist, and the request still succeeds.

 

$ dig @2.3.4.1 community.hughesnet.com

; <<>> DiG 9.11.2 <<>> @2.3.4.1 community.hughesnet.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10027
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;community.hughesnet.com.    IN    A

;; ANSWER SECTION:
community.hughesnet.com. 60    IN    CNAME    c.media-amazon.com.
c.media-amazon.com.    60    IN    A    13.33.253.147

;; Query time: 2 msec
;; SERVER: 2.3.4.1#53(2.3.4.1)
;; WHEN: Fri Dec 01 17:17:45 PST 2017
;; MSG SIZE  rcvd: 89

 

To further prove that, I use an internal LAN ip address that is bogus, and the request fails, because the request is never routed off my local network for the modem to rewrite.

 

$ dig @192.168.1.32 community.hughesnet.com

; <<>> DiG 9.11.2 <<>> @192.168.1.32 community.hughesnet.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

 

It is just completely wrong for Hughesnet to mess with DNS like this.  It breaks so many things, including your own website.

C0RR0SIVE
Associate Professor

You and Jezra would certainly get along -.-

The reason that Hughesnet does it this way is to lessen load on the gateways, and to decrease the amount of time the beams are filled with DNS requests.  It's not going to change any time soon.

@C0RR0SIVE

 

Running a DNS caching server which behaves according to spec is one thing.  Hijacking DNS requests and implementing a broken DNS cache is another.

 

Even if they chose to hijack all DNS requests in order to serve cached responses, they could do so in a way that respects the DNS TTL records, and appropriately discard and refresh stale records.  I would also venture that there are bugs in their code that simply return completely incorrect responses alltogether.

 

Your assertion that "It's not going to change any time soon" either indicates that you have inside knowledge beyond being another customer or that your response is based on historical interactions on this subject.  I'm already aware of how poorly Hughesnet is performing historically.

 

In any case, unless you speak for Hughesnet, I don't find any value in your assertion.  As I understand, you do not speak for Hughesnet.

 

@Amanda, @Liz, should there be any expectation that this will be fixed?

@Liz, you should have a vested interest in having this addressed for your own role in support.  I expect quite a few support requests would be resolved by fixing this fundamental internet protocol violation.  Can you acknowledge that this issue has been forwarded to the network engineers and whether there is any intent to address it?

@sozoridge

As a temporary work-around you can either redirect your DNS traffic over port 443, or use DNSCrypt/DNSSEC instead.  I belive OpenDNS supports DNS over ports other than 53.