Hughesnet Community

Secure DNS (DNSSEC) isn't supported on HughesNet

cancel
Showing results for 
Search instead for 
Did you mean: 
redneckmother
Freshman

Secure DNS (DNSSEC) isn't supported on HughesNet

HughesNet DNS support is miserable. The servers supplied via DHCP are not DNSSEC validating and attempts to use known DNSSEC validating servers are, evidently, intercepted and mangled (TCP/UDP port 53).

I understand that network operators want to intercept and cache as much traffic as possible, but it "breaks the 'net".

Years ago, I requested a time line for proper DNSSEC support, and I'm still waiting for an answer.
13 REPLIES 13
C0RR0SIVE
Associate Professor

redneckmother,

Welcome to the Community!

Sorry, but I personally don't see this happening on Hughesnet (disabling the caching of DNS records)...  As far as the whole DNSSEC thing, I have zero idea, I can't make any comments about that. Amanda or Liz might have an idea though.

The best you can hope for is to set your router to use a third party DNS, and disable Web-Acceleration,but known records at the modems level will still be intercepted by the modem.  The same thing typically happens with most consumer grade routers as well, the router will intercept the DNS request and supply what it knows.

If you leave Web-Accel on, you won't be using your DNS when browsing most websites, and will use what ever DNS the Web Acceleration server is setup to use since it is a proxy.

Thanks,
C0RR.
redneckmother
Freshman

I have an x86_64 based firewall router between my workstations and the hughesnot modem. I've disabled the modem's turbopage, as my router is fully capable of caching non-secure http traffic (and does a really good job, too: 24.45% of traffic for last week).

When I point the firewall to (non-hughes) DNSSEC validating servers, the responses are being mangled by hughes.

Short of hughes ceasing to mess with port 53, I'd really like to have an answer to the question:

 "When will the (DHCP assigned) Hughes DNS servers validate with DNSSEC?"

Gracias
Liz
Moderator
Moderator

Hi redneckmother,

Welcome and thanks for posting! Interesting question, I've sent this to an engineer here at corporate for assistance. I'll post back once I have any news to share.

Thanks,
Liz
If you have a tech or billing question and need help, please start a new thread in the appropriate board. Unsolicited Private Messages may not get replies.

Slow performance? Click me!

Hmmm...

 

A couple of replies in this thread have disappeared since yesterday.

 

Liz replied that Engineering has no plans to support DNSSEC.

 

I expressed dissappointment, and posted a followup question.

 

As I outlined previously, I use a firewall between my local machines and HughesNet (doesn't / shouldn't everyone?).  The firewall solution I employ is successfully deployed on thousands of networks by companies and individuals. A recent update now uses "unbound" (https://unbound.net), and is configured to force DNSSEC validation from upstream resolvers (a good idea, in this day and age).

 

Unfortunately, HughesNet *apparently* caches/spoofs/mangles port 53 traffic, breaking DNSSEC if a user attempts to use DNSSEC from a validating server (say, 8.8.8.8 or 8.8.4.4, or many other servers at other addresses).

 

My current question is "Will HughesNet cease breaking DNSSEC validation traffic to outside servers?"

 

Thank you

Just so that you, and other users don't think the posts had been deleted, Liz posted the other day that they had "locked" the forum database and was in the process of moving all posts made upto that time to this community, and any new posts afterwards would not be moved... Seems her topic about it, was also left behind.

maratsade
Distinguished Professor IV

The post said that anything posted after 5 pm on Tuesday would not make it to the new community. ETA: Liz had also clarified that some posts might be copied over manually, so some things posted to the old community after Tuesday at 5 pm may have been transferred manually, but not everything.

Hi redneckmother,

 

Thank you for recapping the exchange from the legacy community that didn't make it here. I did send your followup question back and await a reply. I noticed another engineer was added to the e-mail chain. I'll keep you updated.

If you have a tech or billing question and need help, please start a new thread in the appropriate board. Unsolicited Private Messages may not get replies.

Slow performance? Click me!

Gentle *ping*.

Good morning, thank you for the ping. I was waiting on clarification on some answers I received, but realized I never got any. I've pinged the engineers back. 

 

If you have a tech or billing question and need help, please start a new thread in the appropriate board. Unsolicited Private Messages may not get replies.

Slow performance? Click me!

OK, here's what I have from engineering:

 

Terminal does not have support for DNSSEC in the current release. It is planned for a future release. 

 

Our terminal handles DNSSEC requests like any other traffic flow to the destination server, in that we don't alter packets.

 

I hope that sheds light on your concerns.

 

If you have a tech or billing question and need help, please start a new thread in the appropriate board. Unsolicited Private Messages may not get replies.

Slow performance? Click me!

Hmmm...  I'm having difficulty believing that port 53 TCP/UDP packets aren't being spoofed or mangled.

 

I tried a different DNSSEC solution on the firewall, "dnsmasq".

 

I pointed the firewall to the following "validating" servers:

 74.113.60.185

 156.154.70.1

 

With DNSSEC enabled, I was unable to resolve any hosts I regularly visit.

 

I tried "dig" against google server 8.8.8.8 as follows:

# dig @8.8.8.8 +sigchase +dnssec www.ipfire.org
;; NO ANSWERS: no more
We want to prove the non-existence of a type of rdata 1 or of the zone:
;; nothing in authority section : impossible to validate the non-existence : FAILED

;; Impossible to verify the Non-existence, the NSEC RRset can't be validated: FAILED

 

Does that help?

Thanks.

Okay, I surrender.

 

Obviously, the DNS caching can't be disabled on an HN9000, and there's no hope in sight.

 

Guess I'll have to look for a NLOS wireless solution.  I think my DNSSEC, data cap, throughput, and latency disappointments justify finding something else.

 

What a pity.

admin5000
New Member

I noticed mainly on social media, slow running jumping computer, many times I'm forced to shutdown and mouse seems to be not responding properly