Blocklists supersede Local DNS records

[devtimi]

Versions

Core version is v6.1.4 (Latest: v6.1.4)
Web version is v6.2.1 (Latest: v6.2.1)
FTL version is v6.2.3 (Latest: v6.2.3)

Platform

• OS and version: Raspbian (Debian) 11
• Platform: Raspberry Pi

Expected behavior

That I'd be able to reroute DNS for a blocklisted domain locally.

Actual behavior / bug

The blocklist supersedes the Local DNS record, making manual overrides impossible without first whitelisting the domain (the "allow" button on the blocked queries list will do). In my opinion, anything you do manually (local DNS override) should override anything done automatically (the blocklists).

Steps to reproduce

Steps to reproduce the behavior:

1. Create a Local DNS record for a domain on a blocklist
2. Try to access that domain
3. The DNS lookup from Pihole returns 0.0.0.0 instead of your Local DNS record

Debug Token

This can be reproduced with any address that's on a blocklist.

Additional context

A personal, sensitive domain I own was hijacked for malicious use. I'm just getting around to using it, but since it's on blocklists I was trying to manually override for local testing. Pihole returns 0.0.0.0 unless the address is whitelisted. Easy, but feels like it should be unnecessary.

[rdwebdesign]

Please post a debug token:

• run pihole -d command.
• when asked to upload the log, answer Y.
• copy only the token and paste here.

[devtimi]

The issue presents with any domain on a blacklist, you do not need my domain. Close the ticket if you wish, but I am not able to provide you the domain I discovered the issue on for this report.

[rdwebdesign]

If I understood correctly, you have the domain blacklisted. Pi-hole will always return 0.0.0.0 for blocked domains. This is the expected behavior.

If you want Pi-hole returning the IP set on "Local DNS record", then remove the blacklist to this domain.

[devtimi]

The list is imported from stevenblack, an automatic action. Creating a Local DNS record is a manual action. This should override the automatic action.

Had the domain been manually blacklisted, then yes I'd agree it could return 0.0.0.0. Local DNS records should override remote lists though, in my opinion. Maybe a difference of opinion, that's okay because it can be resolved by whitelisting the domain.

[rdwebdesign]

Local DNS records should override remote lists though, in my opinion.

Looks like this is a feature request, not a bug.

Pi-hole is working as expected, but if you want to open open feature requests, please access our our Discourse Forum - Feature Requests.

[TheNec]

Sorry for adding my unqualified non voter opinion but this issue seems quite interesting.

I would also say that the manual intervention should (always) be preferred over the automatic behavior but we run into a special case here:

There are basically more or less two operations that oppose each other - blocking and allowing the same thing at the same time while priority is then given to blocking.

From the default allow/block order logic derived the override for the redirect should therefore work and initially it seems like a pi-hole bug or at least unforeseen/undesired behavior.

I think the main problem here is that dnsmasq was - at least in the past - not developed for using externally created block lists in mind and a potential allow/block equinox situation that may arise as a result of that.

Asking an AI (Quen) about the designation when unexpected behavior in software development occures due to an in the past not expected use case gives several answers where classification as a semantic or logical error seems to fit best for me.

Long story short (imho!): FTL/dnsmasq ([no|low]-prio) bug -> report upstream to @simonkelley

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[DL6ER]

There are basically more or less two operations that oppose each other - blocking and allowing the same thing at the same time while priority is then given to blocking.

No, actually, not. If you allow a domain inside the Pi-hole ecosystem, it will always win. What is done here is adding local record and expecting it to win. However, dnsmasq is only ever asked for domains when Pi-hole does not block it before. Hence, the solution here is, as already explained by @devtimi to allow the domain in Pi-hole so it will never be blocked.

I can see why this is maybe not exactly what users expect but - technically - it simply comes from the fact that we are dealing with split-horizons here. FTL does "its own thing" using a balanced tree which is optimized for very large numbers of domains (logarithmic lookup times) while dnsmasq is less suitable for very large lists (although it also tries to be smart here using hash buckets). Both approaches live besides each other and do not interfere . Mainly because it would be slow at runtime but, perhaps even more important, it would introduce another (complicated) interface between dnsmasq of pihole-FTL which would put additional complexity on (modifying and) importing future dnsmasq patches.

Hence, thinking about this for a second time, I still think what we currently do is "the right thing". But we can surely enough improve on documentation, maybe even on the page where local DNS records are managed. We can(/should) obviously not modify your local /etc/hosts to add such a comment.

[yubiuser]

I agree, a comment might be helpful to explain the interaction beween pihole and dnsmasq.
I briefly thought about automatically adding a whitelisted domain for each local dns record but this might have other unexpected side-effects and is hard to explain to users also.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.