With Core 162, DNS forwarding of foreign zones doesn't work any more when DNSSEC is enabled. The request reaches the target nameserver, but then seems to get dropped internally, so the requesting client gets an unresolvable message from IPFire's NS. I reverted a test-instance back to Core 159 where I came from and it worked again as expected. Current work-around is to disable DNSSEC for the affected domains. Thread in forum: https://community.ipfire.org/t/dns-forwarding-broken-in-162/7112
Does unbound log anything?
Indeed it does: Jan 22 12:23:27 ipfire unbound: [3019:0] info: validation failure <host.company.corp. AAAA IN>: no NSEC3 records from 192.5.5.241 for DS corp. while building chain of trust The zone forward in question is defined for "company.corp". Interesting is, that forwarding the zone-queries for the zone that the IPFire-host itself belongs to, succeeds when DNSSEC is enabled, although it's the same target nameserver. Is it correct, that it queries the server at 192.5.5.241? This looks a bit strange to me.
(In reply to ChrisK from comment #2) > Jan 22 12:23:27 ipfire unbound: [3019:0] info: validation failure > <host.company.corp. AAAA IN>: no NSEC3 records from 192.5.5.241 for DS corp. > while building chain of trust > > The zone forward in question is defined for "company.corp". This is correct behaviour. The "corp" zone is not signed and therefore it cannot be validated. You will need to have the checkbox set to disable DNSSEC. unbound does exactly what it is asked to do. > ms@rice-oxley ~ % dig DNSKEY corp > > ; <<>> DiG 9.10.6 <<>> DNSKEY corp > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59460 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ;; QUESTION SECTION: > ;corp. IN DNSKEY > > ;; AUTHORITY SECTION: > . 773 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022020700 1800 900 604800 86400 > > ;; Query time: 47 msec > ;; SERVER: 172.28.1.1#53(172.28.1.1) > ;; WHEN: Mon Feb 07 11:21:14 GMT 2022 > ;; MSG SIZE rcvd: 108 > Interesting is, that forwarding the zone-queries for the zone that the > IPFire-host itself belongs to, succeeds when DNSSEC is enabled, although > it's the same target nameserver. > > Is it correct, that it queries the server at 192.5.5.241? This looks a bit > strange to me. It would have to ask the parent zone for any DS records which is in this case the root zone. And 192.5.5.241 is one of the root name servers. So this is correct.
Why did this not occur with core 159? So, it rather was a but that it worked before while the checkbox was ticked? Anyway, your answer makes sense to me. So I think the bug can be closed.
We updated unbound, but I cannot find anything in the change log that references this change: > https://www.nlnetlabs.nl/projects/unbound/download/#unbound-1-14-0