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, 188.8.131.52 or 184.108.40.206, or many other servers at other addresses).
My current question is "Will HughesNet cease breaking DNSSEC validation traffic to outside servers?"
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.
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.
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.
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.
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.
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:
With DNSSEC enabled, I was unable to resolve any hosts I regularly visit.
I tried "dig" against google server 220.127.116.11 as follows:
# dig @18.104.22.168 +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?
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.