DNSSEC validation and local domains


I'l like to follow up on this question: Disable DNSSEC for specific domains?

I'm running a local unbound DNSSEC-validating server. It is also configured to forward local forward/reverse lookups to the router's dnsmask server. This is done by specifically specifying the zones are not dnssec-secured (domain-insecure directive).

So I can disable DNSSEC and everything works, bad zones are not resolved, local zones are, all good. But I would liks to also be able to configure LAN clients to trust the pi-hole resolver by having it forward the validation flag (ad).

The issue is that pihole-FTL does not forward the flag with DNSSEC disabled, and does not forward the un-validated local responses (lacking the flag) with DNSSEC enabled.

If there's no plan on allowing insecure zones, there could at least be an option to forward DNSSEC trust data without validating it, so a local resolving cache could still be used and pass on the domains + flags, and client configured to trust pi-hole would be able to tell if DNS data was signed (which I think could at least be useful to automatically trust ssh keys with signed fingerprints in DNS).

From your description, it is not clear how Pi-hole is involved here, i.e. where in the DNS resolution chain have you placed your Pi-hole?

Also, please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

I'm not sure how a debug log will help besides what I told you already - I have a trusted upstream DNS cache that does DNSSEC validation and everything works as advertised. Pcaps showing the behavior would be much more helpful...

Basically besides blocking domains that fails validation, DNSSEC also allows clients to see if their request as authenticated, but that works only if the forwarder doesn't strip out the ad bit from the replies.

With DNSSEC validation disabled, the bits are removed as if domains were not authenticated, but when enabled it's doing nsec3 validation and doesn't return an answer for local domains that doesn't provide the appropriate records to disable nsec3 on them.

If we could have an option to trust the upstream's ad bit for DNSSEC validation then my current upstream configuration would be sufficient to forward local domains, and pi-hole would simply pass on all the answers unaltered.

A debug log would have allowed us to derive if and how your unbound is configured as your Pi-hole's upstream, it would have shown if and how you'd enabled Pi-hole's Conditional Fowarding, it may have included hints about the router you're are using (which may have allowed me to check against reported DNSSEC issues for it, e.g. DNSSEC and local domain - #5 by Bucking_Horn), it may have shown us some query results, and it would have spared me from typing all this. :wink:

Insecure zones can be added by specifying them together with the responsible upstream server, like:


which means that the zone my.home is served by
DNSSEC is disabled for this zone by default unless you provide a trust-anchor.

This is possible, too. There is the config option proxy-dnssec for this.

Quoting the dnsmasq man page:

Copy the DNSSEC Authenticated Data bit from upstream servers to downstream clients. This is an alternative to having dnsmasq validate DNSSEC, but it depends on the security of the network between dnsmasq and the upstream servers, and the trustworthiness of the upstream servers. Note that caching the Authenticated Data bit correctly in all cases is not technically possible. If the AD bit is to be relied upon when using this option, then the cache should be disabled using --cache-size=0. In most cases, enabling DNSSEC validation within dnsmasq is a better option. See --dnssec for details.

@DL6ER Thanks - that's exactly what I was looking for. Is there any way the other thread (linked with my question) could be updated to include this information? I believe this is exactly what the OP wanted, and the answer was an outright "no".

I'll test, then maybe see if the pi-hole/unbound instructions could be updated to reflect this (tbh I set it up a while back and haven't checked for updates)...