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