DNS zones does not work after update

Hi!

I’ve just upgraded from Core Update 202 to 203 and DNS resolving through zones doesn’t work any more.

I’m using 3 ipfire firewalls to simulate 3 datacenters. All of them are connected using Wireguard. I’ve set the zones dc01.local, dc02.local and dc03.local in Network → DNS Forwarding on all firewalls and it worked on Core Update 202.

After the update I can resolve all the hosts inside one zone (eg from host in dc01 to host in dc01) but I’m not able to resolve hosts in the other zones (from dc01 to dc02 or dc03 and other combinations). Have I missed something after the upgrade? Or wasn’t this meant to work like that?

Please note that in the release announcement

https://www.ipfire.org/blog/ipfire-2-29-core-update-203-released

it mentions

Please note: Forwarded zones can no longer be specified as fully-qualified domain names. You now need to replace any entries on the DNS Forwarding page that use FQDNs with IP addresses.

This is a limitation of knot resolver.

This are my settings.

My Wireguard RoadWarrior is not resolving the zones as well, neither the one connected to.

Okay, as you are already using IP’s then I can’t help further as I don’t use DNS Forwarding.

Will have to wait and see if there are any other users having similar problems.

During the Testing phase the only issue that was flagged was where the nameserver was defined as a FQDN, so different to your situation.

I need the same feature and configured dns forwarding as the TO, but i don’t understand these required actions:

Forwarded zones can no longer be specified as fully-qualified domain names. You now need to replace any entries on the DNS Forwarding page that use FQDNs with IP addresses.

A conditional dns forwarding always needs the domain name (like domain.localdomain) and the ip-adress of the dns-resolver to what the dns-request is forwarded to.

Where and what ip-adress should i put in? I don’t get it.

And: For Windows domain zones on windows domaincontrollers/dns-servers I used a stub-zone config file for unbound in /etc/unbound/local.d like this:

server:	
	domain-insecure: "domain.lan"

stub-zone:
	name: "domain.lan"
	stub-addr: 192.168.123.210
	stub-addr: 192.168.123.211
	stub-prime: yes

What about stub-zones?

Just tested some more and would like to share:

I’m connected, as said, with Wireguard RoadWarrior into the network of the virtual data centers using firewall301.dc03.local. The one is in the hosts list under Network → Edit Hosts. Using nslookup I’m getting timeouts. Now I need first to know if DNS is listening just to the firewalls “native” (green) subnet? My RoadWarrior gets an IP from 192.168.203.0/24 and the green network is 192.168.103.0/24 on this firewall.

If this is the case, other firewalls can’t reach DNS from other networks as well and therefor can’t resolve the zones.

bbele@BB-School01:~$ nslookup firewall301.dc03.local
;; communications error to 192.168.103.254#53: timed out
;; communications error to 192.168.103.254#53: timed out
;; communications error to 192.168.103.254#53: timed out

Previously the DNS-Server entry was checked for either being a valid FQDN or IP. This worked with unbound.

Now that entry must always be an IP other wise it will show an error message saying Invalid IP Address as Knot Resolver only works with IPs for the forwarded server.

Just moving on with some tests:

This looks just the zones are not forwarded at all but the nameservers - firewalls are reachable and are listening. I’ll try to find out where the zone caching or forwarding should be.

[root@firewall301 ~]# nslookup witness101.dc01.local
;; Got SERVFAIL reply from 127.0.0.1
Server:		127.0.0.1
Address:	127.0.0.1#53

** server can't find witness101.dc01.local: SERVFAIL

[root@firewall301 ~]# nslookup witness101.dc01.local 192.168.101.254
Server:		192.168.101.254
Address:	192.168.101.254#53

Non-authoritative answer:
Name:	witness101.dc01.local
Address: 192.168.101.131

EDIT: I think zoning needs some more work. The /var/lib/knot-resolver/zones folder is not populated. Might be something but I’m not sure if this could be solved with the config.yaml in /etc/knot-resolver.

[root@firewall301 knot-resolver]# pwd
/var/lib/knot-resolver
[root@firewall301 knot-resolver]# ls -la zones/
total 8
drwxr-xr-x 2 knot-resolver knot-resolver 4096 Jul 14 15:52 .
drwxr-xr-x 3 knot-resolver knot-resolver 4096 Jul 20 13:30 ..

Ah ok, then my entries are already as they should be. And what about stub zones? Are those possible with knot resolver?

Edit: I upgraded my home system to Core 203 and conditional dns forwarding through openvpn site2site tunnel is working for me.