"Also forward unqualified host names" creates DNSSEC loop

Since the lastest change (Conditional forwarding: Also forward unqualified host names by DL6ER · Pull Request #4287 · pi-hole/pi-hole · G) Pi-hole will forward Non-FQDNs to rev-server if this is enabled.
In my config, my router is my DHCP server (distribution Pi-hole as DNS server) and it uses Pi-hole for itself as upstream server.

After installing a new client, which has DNSSEC enabled by default, a DNS loop happend: e.g. the client requested query[DNSKEY] com which is a non-FQDN and therefore it was sent to my rev-server instead of my local unbound instance. The router didn't know what to do and sent it back to Pi-hole creating a nice loop.

Bildschirmfoto zu 2021-08-27 12-07-25

May workaround was to manually remove server=//IP from the dnsmasq config file.

I'm not sure how to fix this - maybe make an exception for DNSSEC not to be send to the rev-server? Make sure in such a configuration, the router des not use Pi-hole as upstream?

It's not only DNSKEY and DS but also SOA which looped massively.

Use DNSSEC is off on Pi-hole as unbound is handling DNSSEC.

That's an interesting configuration.

Is disabling DNSSEC on that client an option?

Do you require your router to use Pi-hole as upstream?

Alternatively, I guess you could also send tlds to Pi-hole's default upstreams, e.g. server=/org/com/net/arpa/de/# - but then there are quite a few tlds.

I'm not sure either if silently sending only certain query types to standard upstreams would be a good idea. That may break more sophisticated DNS setups where a local full DNS server would hold the respective records and serve local requests differently than outside ones.

Probably, haven't played that much with it. It's a Pi audio streamer OS where I didn't want to fiddle that much.

Not really, depends on my current level of paranoia :slight_smile:

.. a lot. See https://www.netmeister.org/blog/tlds.html

I'm not convinced either. But I think my setup is not uncommon (think of FritzBoxes where users want to filter the guest network as well), so we will see this behavior more often now.

Ah, I see. This is indeed an interesting side-effect of what we changed recently.

One question though: Did you untick the first check box?

If so, please re-check it (the default) and see if this fixes the issue. I'm fine with undoing the recent change if this still doesn't fix it, however, I think it should and you should probably not have unticked the box in the first place when your router is conditional upstream and will send things back it is not authoritative for.

I'm not sure if it would be, as far as the client is concerned (or how to validate that).

I am not aware of any client OS that would enable DNSSEC by default.
I believe that Windows DNSSEC support would even be exclusive to the server OS line-up.

It's Hifiberry OS (GitHub - hifiberry/hifiberry-os: Linux distribution optimized for audio playback), based on buildroot and uses systemd-resolved for name resolution. They even implemented a script to disable DNSSEC for ntpd to break the chicken-egg-problem with incorrect time, ntp and DNSSEC

I do have it unticked now, but I guess it was enabled initially (did a bit of troubleshooting with the options).

I'm not sure if I can follow you here. You want me to enable CF and tick "Never forward non-FQDNs"? But what we really want is the opposite (or?): non-FQDN to be sent upstream, e.g. to get DS for com.

Additionally, I don't unterstand which option takes precedence: server=//IP or "Never forward non-FQDNs"? Being able to set both seems contradictory.

I tested for that when valuating the PR:
domain-needed as set by Never forward non-FQDNs controls whether dnsmasq forwards plain names to any upstreams, effectively also nullifying server=//.

1 Like


If this is how it should work, it doesn't

chrko@ThinkPad-X230:~$ dig com DNSKEY
Aug 27 17:56:35 dnsmasq[6160]: query[DNSKEY] com from
 Aug 27 17:56:35 dnsmasq[6160]: forwarded com to


I think the culprit is

-D, --domain-needed

Tells dnsmasq to never forward A or AAAA queries for plain names, without dots or domain parts, to upstream nameservers. If the name is not known from /etc/hosts or DHCP then a "not found" answer is returned.

It's not an A nor an AAAA query.

1 Like

Then the solution will be to make adding server=// also depending on the check box.