No, I don't think that any of the changes after that commit would have helped.
What I need to have is a test that allows me to identify if these name servers are able to pass on the public key of the root zone.
If so, then DNSSEC would work fine in recursor mode.
If not, unbound should now disable DNSSEC validation.
What is the output of "/etc/init.d/unbound restart" on that system?
-Michael
On Thu, 2017-03-30 at 13:21 -0500, Paul Simmons wrote:
On Thu, 2017-03-30 at 17:51 +0100, Michael Tremer wrote:
Hey Paul,
I really don't want you to switch away from IPFire since there is no need to. We will get this fixed.
And although this is a corner case I am willing to work on this. However I cannot test.
So just to get me up to date again: Did you apply the changes from Core Update 110? Did that work or not?
-Michael
On Sat, 2017-03-25 at 10:20 -0500, Paul Simmons wrote:
On Wed, 2017-03-08 at 10:19 -0600, Paul Simmons wrote:
On Wed, 2017-03-08 at 12:09 +0000, Michael Tremer wrote:
Hmm...
That's interesting that only AAAA records fail. No idea why the system is resolving those any ways, but hey...
So when you do
dig @198.41.0.4 a.root-servers.net AAAA +dnssec
does that work?
What does
dig @8.8.8.8 +sigchase +dnssec www.ipfire.org
do?
-Michael
---->% massive snippage here %<----
Sorry for the delay. I have to chase everyone off the network and reboot with another disk (development image) to test, then have to reboot with Core105 and DNSSEC disabled to resume email :).
Here are the results:
# dig @198.41.0.4 a.root-servers.net AAAA +dnssec
; <<>> DiG 9.11.0-P3 <<>> @198.41.0.4 a.root-servers.net AAAA +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65258 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: Message has 23 extra bytes at end
;; QUESTION SECTION: ;a.root-servers.net. IN AAAA
;; Query time: 1 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Wed Mar 08 09:56:11 CST 2017 ;; MSG SIZE rcvd: 59
# dig @8.8.8.8 +sigchase +dnssec www.ipfire.org ;; Warning: Message parser reports malformed message packet. ;; 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
Thank you, Paul
Additional information:
On Core105, I have an override in /etc/sysconfig/dnsmasq: ENABLE_DNSSEC=0
If I remove this, DNS resolution outside of my private network fails.
I've had a long conversation with HughesNet Community Support (such as it is), to no avail.
Hughes has no plans to support DNSSEC in the near future, and there's no way to prevent the modem (HN9000) from caching / spoofing / mangling DNS traffic.
There are no other providers available - no DSL, no cable, no fiber, no wireless, no cellular, no anything. If I had the funds, I'd create my own NLOS WISP and make a tidy profit out here "in the sticks". Goodness knows, I'd like a reprieve from high cost, data caps, high latency, rain fade, and miserable throughput.
Please, is there any way to fall back to insecure DNS with IPFire's unbound configuration? I realize my situation is a "corner case", but I like IPFire, have a lot of time and effort invested, and am loath to switch to a different firewall.
Best regards, Paul
Hey Michael. Sorry to be a pain. Thank you for your help.
I tested with commit c016773b9816ad9be4ffc8643c30457e87c094e3 and had no luck.
I tried using both the ISP provided DNS and known "good" validating servers.
Shall I rebuild the test image with a later commit?
Paul