"Also forward unqualified host names" creates DNSSEC loop

[yubiuser]

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.

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?

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

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

[Bucking_Horn]

That's an interesting configuration.

@yubiuser

After installing a new client, which has DNSSEC enabled by default

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.

@yubiuser

I'm not sure how to fix this - maybe make an exception for DNSSEC not to be send to the rev-server ?

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.

[yubiuser]

@Bucking_Horn

Is disabling DNSSEC on that client an option?

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

@Bucking_Horn

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

Not really, depends on my current level of paranoia

@Bucking_Horn

are quite a few tlds.

.. a lot. See TLDs -- Putting the '.fun' in the top of the DNS

---

@Bucking_Horn

I'm not sure either if silently sending only certain query types to standard upstreams would be a good idea.

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.

[DL6ER]

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.

[Bucking_Horn]

@yubiuser

But I think my setup is not uncommon

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.

[yubiuser]

@Bucking_Horn

I am not aware of any client OS that would enable DNSSEC by default.

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

[yubiuser]

@DL6ER

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

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

---

@DL6ER

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 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.

[Bucking_Horn]

@yubiuser

Additionally, I don't unterstand which option takes precedence:

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=//.

[yubiuser]

Thanks.

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

---

addn-hosts=/etc/pihole/local.list
addn-hosts=/etc/pihole/custom.list
localise-queries
no-resolv
cache-size=10000
log-queries
log-facility=/var/log/pihole.log
local-ttl=2
log-async
server=127.0.0.1#5335
domain-needed
expand-hosts
bogus-priv
local-service
rev-server=10.0.1.1/24,10.0.1.1
server=//10.0.1.1
server=/fritz.box/10.0.1.1

chrko@ThinkPad-X230:~$ dig com DNSKEY

Aug 27 17:56:35 dnsmasq[6160]: query[DNSKEY] com from 10.0.1.31
 Aug 27 17:56:35 dnsmasq[6160]: forwarded com to 10.0.0.1

---

Add

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.

[DL6ER]

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