On Sun, 2017-04-02 at 19:03 +0100, Michael Tremer wrote:
Hi,
this does help, yes.
You are falling back to recursor mode which is not really what should happen. That means the test does not indicate correctly what I hoped it would do.
Are those name servers your ISP is forcing you to use publicly available? If so I could test on my own.
Best, -Michael
On Sun, 2017-04-02 at 11:37 -0500, Paul Simmons wrote:
On Fri, 2017-03-31 at 17:53 +0100, Michael Tremer wrote:
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
Finally got a test window... made the best of it.
Output from unbound restart:
# /etc/init.d/unbound restart Stopping Unbound DNS Proxy... [ OK ] Starting Unbound DNS Proxy... [ OK ] Ignoring broken upstream name server(s): 67.142.173.10 67.142.173.11 [ WARN ] Falling back to recursor mode [ WARN ]
A couple of simple resolution tests:
# nslookup www.google.com Server: 127.0.0.1 Address: 127.0.0.1#53
** server can't find www.google.com: SERVFAIL
# host www.google.com Host www.google.com not found: 2(SERVFAIL)
Export of unbound log (reverse chronological):
IPFire diagnostics Section: unbound Date: April 02, 2017
10:48:30 unbound: [3763:1] info: validation failure self- repair.mozilla.org. AAAA IN 10:47:31 unbound: [3763:0] info: validation failure ns2.cctld.co. AAAA IN 10:47:28 unbound: [3763:1] info: validation failure c.ns.nic.cz. AAAA IN 10:47:28 unbound: [3763:1] info: validation failure a.ns.nic.cz. AAAA IN 10:47:28 unbound: [3763:1] info: validation failure b.ns.nic.cz. AAAA IN 10:47:28 unbound: [3763:1] info: validation failure d.ns.nic.cz. AAAA IN 10:47:24 unbound: [3763:0] info: validation failure ns4.cctld.co. AAAA IN 10:47:24 unbound: [3763:0] info: validation failure ns3.cctld.co. AAAA IN 10:47:24 unbound: [3763:0] info: validation failure ns5.cctld.co. AAAA IN 10:47:24 unbound: [3763:0] info: validation failure ns1.cctld.co. AAAA IN 10:47:24 unbound: [3763:0] info: validation failure ns6.cctld.co. AAAA IN 10:47:03 unbound: [3763:0] info: validation failure ns02.fedoraproject.org. AAAA IN 10:47:01 unbound: [3763:0] info: validation failure ns05.fedoraproject.org. AAAA IN 10:46:51 unbound: [3763:1] info: validation failure ns3.cloudflare.com. AAAA IN 10:46:51 unbound: [3763:1] info: validation failure ns6.cloudflare.com. AAAA IN 10:46:50 unbound: [3763:1] info: validation failure ns7.cloudflare.com. AAAA IN 10:46:49 unbound: [3763:0] info: validation failure fedoraproject.org. AAAA IN 10:46:38 unbound: [3763:1] info: validation failure ns5.cloudflare.com. AAAA IN 10:46:38 unbound: [3763:1] info: validation failure ns4.cloudflare.com. AAAA IN 10:44:08 unbound: [3763:0] info: validation failure www.facebook.c om .l ocaldomain. AAAA IN 10:43:28 unbound: [3763:0] info: start of service (unbound 1.6.1). 10:43:28 unbound: [3763:0] notice: init module 1: iterator 10:43:28 unbound: [3763:0] notice: init module 0: validator 10:43:26 unbound: [1407:0] info: 32.000000 64.000000 4 10:43:26 unbound: [1407:0] info: 16.000000 32.000000 5 10:43:26 unbound: [1407:0] info: 8.000000 16.000000 4 10:43:26 unbound: [1407:0] info: 4.000000 8.000000 2 10:43:26 unbound: [1407:0] info: 2.000000 4.000000 3 10:43:26 unbound: [1407:0] info: 0.524288 1.000000 4 10:43:26 unbound: [1407:0] info: 0.262144 0.524288 1 10:43:26 unbound: [1407:0] info: 0.131072 0.262144 1 10:43:26 unbound: [1407:0] info: 0.004096 0.008192 2 10:43:26 unbound: [1407:0] info: 0.000000 0.000001 8 10:43:26 unbound: [1407:0] info: lower(secs) upper(secs) recursions 10:43:26 unbound: [1407:0] info: [25%]=0.00512 median[50%]=2.66667 [75%]=17.6 10:43:26 unbound: [1407:0] info: histogram of recursion processing times 10:43:26 unbound: [1407:0] info: average recursion processing time 10.613770 sec 10:43:26 unbound: [1407:0] info: server stats for thread 1: requestlist max 40 avg 6.79412 exceeded 0 jostled 0 10:43:26 unbound: [1407:0] info: server stats for thread 1: 76 queries, 42 answers from cache, 34 recursions, 0 prefetch, 0 rejected by ip ratelimiting 10:43:26 unbound: [1407:0] info: 32.000000 64.000000 4 10:43:26 unbound: [1407:0] info: 16.000000 32.000000 9 10:43:26 unbound: [1407:0] info: 8.000000 16.000000 6 10:43:26 unbound: [1407:0] info: 4.000000 8.000000 6 10:43:26 unbound: [1407:0] info: 2.000000 4.000000 5 10:43:26 unbound: [1407:0] info: 1.000000 2.000000 3 10:43:26 unbound: [1407:0] info: 0.524288 1.000000 5 10:43:26 unbound: [1407:0] info: 0.262144 0.524288 1 10:43:26 unbound: [1407:0] info: 0.131072 0.262144 6 10:43:26 unbound: [1407:0] info: 0.016384 0.032768 1 10:43:26 unbound: [1407:0] info: 0.000000 0.000001 9 10:43:26 unbound: [1407:0] info: lower(secs) upper(secs) recursions 10:43:26 unbound: [1407:0] info: [25%]=0.212992 median[50%]=3 [75%]=15 10:43:26 unbound: [1407:0] info: histogram of recursion processing times 10:43:26 unbound: [1407:0] info: average recursion processing time 8.866802 sec 10:43:26 unbound: [1407:0] info: server stats for thread 0: requestlist max 63 avg 17.7679 exceeded 0 jostled 0 10:43:26 unbound: [1407:0] info: server stats for thread 0: 83 queries, 28 answers from cache, 55 recursions, 1 prefetch, 0 rejected by ip ratelimiting 10:43:26 unbound: [1407:0] info: service stopped (unbound 1.6.1). 10:42:07 unbound: [1407:0] info: validation failure sfba.sns- pb.isc.org. AAAA IN 10:42:03 unbound: [1407:0] info: validation failure adns3.upenn.edu. AAAA IN 10:42:02 unbound: [1407:0] info: validation failure ord.sns- pb.isc.org. AAAA IN 10:42:01 unbound: [1407:0] info: validation failure ams.sns- pb.isc.org. AAAA IN 10:41:57 unbound: [1407:0] info: validation failure adns2.upenn.edu. AAAA IN 10:41:51 unbound: [1407:0] info: validation failure adns1.upenn.edu. AAAA IN 10:41:42 unbound: [1407:0] info: validation failure ns05.fedoraproject.org. AAAA IN 10:41:42 unbound: [1407:0] info: validation failure ns02.fedoraproject.org. AAAA IN 10:41:41 unbound: [1407:1] info: validation failure ns05.fedoraproject.org. AAAA IN 10:41:41 unbound: [1407:1] info: validation failure ns02.fedoraproject.org. AAAA IN 10:41:31 unbound: [1407:0] info: validation failure fedoraproject.org. AAAA IN 10:41:23 unbound: [1407:1] info: validation failure fedoraproject.org. AAAA IN 10:41:19 unbound: [1407:0] info: validation failure ns3.pch.net. AAAA IN 10:41:19 unbound: [1407:0] info: validation failure anyns.pch.net. AAAA IN 10:41:18 unbound: [1407:0] info: validation failure ns2.pch.net. AAAA IN 10:41:04 unbound: [1407:0] info: validation failure ns5.cloudflare.net. AAAA IN 10:41:04 unbound: [1407:0] info: validation failure ns4.cloudflare.net. AAAA IN 10:41:03 unbound: [1407:0] info: validation failure ns2.cloudflare.net. AAAA IN 10:41:03 unbound: [1407:0] info: validation failure ns3.cloudflare.net. AAAA IN 10:41:02 unbound: [1407:0] info: validation failure ns1.cloudflare.net. AAAA IN 10:40:55 unbound: [1407:1] info: validation failure fireinfo.ipfire.org. AAAA IN 10:40:54 unbound: [1407:1] info: validation failure ns2.lightningwirelabs.com. AAAA IN 10:40:54 unbound: [1407:1] info: validation failure ns1.lightningwirelabs.com. AAAA IN 10:40:54 unbound: [1407:1] info: validation failure ns3.lightningwirelabs.com. AAAA IN 10:40:27 unbound: [1407:0] info: validation failure fireinfo.ipfire.org.localdomain. AAAA IN 10:39:36 unbound: [1407:0] info: start of service (unbound 1.6.1). 10:39:36 unbound: [1407:0] notice: init module 1: iterator 10:39:36 unbound: [1407:0] notice: init module 0: validator
Hope this helps. Used ISP (HughesNet) DNS servers as provided through DHCP on RED. Ping of 8.8.4.4 was good during the test window.
Best, Paul
Thanks for the feedback, Michael.
I can't say for sure that the servers are available to you... I'd recommend testing them. If you have a suite of tests you'd like me to perform, I'll "schedule" another window. (As in: "Oops, the 'net is down for a few minutes... sorry... I have three of my best men working on it right now. Their names are Larry, Moe, and Curly." :-)
(Reiterating) The ISP supplied (proprietary) modem caches DNS, and that setting can't be changed (I've b*tched about it, but they don't care). Don't know if that impacts anything.
Thanks again for your efforts! Paul