Here is an example of exactly what I am talking about. I created a new ipfire server, the latest build/release (148). And as I added test entries to the DNS configuration, each one worked until I added one more, and the newest one, fails to resolve as a forward look up. But reverse lookup does work.
# cat /etc/unbound/hosts.conf
# This file is automatically generated and any changes
# will be overwritten. DO NOT EDIT!
local-data: "wall.dd.org 60 IN A 192.168.1.91"
local-data: "184.108.40.206.in-addr.arpa 60 IN PTR wall.dd.org"
local-zone: dd.org typetransparent
local-zone: local typetransparent
local-data: "cable.dd.org 60 IN A 192.168.100.1"
local-data: "220.127.116.11.in-addr.arpa 60 IN PTR cable.dd.org"
local-data: "green.dd.org 60 IN A 192.168.1.91"
local-data: "red.dd.org 60 IN A 192.168.0.91"
local-data: "18.104.22.168.in-addr.arpa 60 IN PTR red.dd.org"
local-data: "zzde61263.local 60 IN A 192.168.1.166"
local-data: "22.214.171.124.in-addr.arpa 60 IN PTR zzde61263.local"
[root@wall ~]# nslookup 192.168.1.166
126.96.36.199.in-addr.arpa name = zzde61263.local.
[root@wall ~]# nslookup zzde61263.local
** server can't find zzde61263.local: NXDOMAIN
Once this error results, the environment goes downhill fast, once working forward references stop working, until you end up with a mix-matched scenario where some forward lookups work, some don’t. Stopping and restarting DNS service does not seem to make a difference every time, based on the testing I have been doing. In this latest test, stopping the service and restarting, did improve the situation, but such is not a solution, at best, a work-around.
Unfortunately, in effect, this issue, makes ipFire completely useless to us, in reference to any DNS resolution functions. This is the 3rd time I have been consistently able to recreate the issue. Sometimes it takes 100 entries, times less, in this last case, about 5 A/PTR pairs.
Before the errors, cable.dd.org forward and reverse lookup worked fine, now after the error, it fails.
[root@wall ~]# nslookup cable.dd.org
** server can't find cable.dd.org: NXDOMAIN
[root@wall ~]# nslookup 192.168.100.1
188.8.131.52.in-addr.arpa name = cable.dd.org.
Are we completely missing something here? As I noted before, never seen this behavior on a BIND DNS server instance, that was configured as in should be, in an appropriate manner. I guess this issue has not gained exposure as maybe it should? Given that serious (scaled) enironments likely have dedicated DNS resources, not integrated to a firewall? Just a guess?