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