public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] DNS: Fall back to permissive mode if recursor mode is unavailable
Date: Sun, 02 Apr 2017 19:03:47 +0100	[thread overview]
Message-ID: <1491156227.12811.1.camel@ipfire.org> (raw)
In-Reply-To: <1491151036.13033.2.camel@hughes.net>

[-- Attachment #1: Type: text/plain, Size: 14916 bytes --]

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.com
> .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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2017-04-02 18:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1490979195.2643.88.camel@ipfire.org>
2017-04-02 16:37 ` Paul Simmons
2017-04-02 18:03   ` Michael Tremer [this message]
2017-04-02 19:07     ` Paul Simmons
     [not found] <1490455220.20288.4.camel@hughes.net>
2017-03-30 16:51 ` Michael Tremer
2017-03-30 18:21   ` Paul Simmons
     [not found] <1488903324.21248.2.camel@hughes.net>
2017-03-08 12:09 ` Michael Tremer
2017-03-08 16:19   ` Paul Simmons
2017-03-01 16:11 Michael Tremer
2017-03-01 16:17 ` Michael Tremer
2017-03-01 18:00   ` Paul Simmons
2017-03-03 20:54     ` Paul Simmons
2017-03-05 11:42       ` Michael Tremer
2017-03-06 18:18         ` Paul Simmons
2017-03-06 21:00           ` Michael Tremer
2017-03-06 21:47             ` Paul Simmons
2017-03-06 22:37               ` Michael Tremer
2017-03-06 23:29                 ` Paul Simmons
2017-03-07 12:06                   ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1491156227.12811.1.camel@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox