I updated my Pi-hole 5.x to development-v6 yesterday.
Now the dashboard is only showing IP's not DNS names as in 5.x where all DNS names were correctly shown for both Top and Blocked clients.
All client names are visible/readable on DHCP page but not on dashboard...
Any setting I should change to make this work again?
Token:
https://tricorder.pi-hole.net/9St1ci41/
Thanks in advance!!
DL6ER
January 28, 2024, 9:13pm
2
Sorry for the delay in replying. Are you using your Pi-hole also as DHCP server?
If so, could you log into your Pi-hole using SSH and run
dig -x 192.168.0.83 @127.0.0.1
What is the output?
Hi,
Yes Pi-hole is managing both DHCP and DNS.
Output:
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> -x 192.168.0.83 @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24553
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;83.0.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
83.0.168.192.in-addr.arpa. 0 IN PTR Jockes_M10_Plus.groupwork.
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Mon Jan 29 07:08:58 CET 2024
;; MSG SIZE rcvd: 93
(The IP belongs to an old-ish Android tablet)
Note:
Installation is updated from 5.x (latest available ~2 weeks ago) to 6.x dev.
Token:
https://tricorder.pi-hole.net/inQrnq57/
DL6ER
January 29, 2024, 3:14pm
4
This shows that - in theory - local name resolution does work as expected. Also your resolver settings are as default per your debug log. Unfortunately, this means we need to dive a bit deeper, but that won't be a problem.
Please start off with
sudo service pihole-FTL stop
sudo pihole-FTL --config debug.resolver true
sudo rm /var/log/pihole/FTL.log
sudo service pihole-FTL start
After a few minutes, go to /var/log/pihole/FTL.log
and check for messages beginning with DEBUG_RESOLVER
. Without knowing what is causing the issue, I cannot really say what to look out for but maybe you can simply provide some of those lines here and we can check together. You can also send them to my via a private message if you prefer this for privacy reasons.
Thanks a lot for helping!
Log (snip) sent.
Stopped logging with:
sudo service pihole-FTL stop
sudo pihole-FTL --config debug.resolver false
sudo rm /var/log/pihole/FTL.log
sudo service pihole-FTL start
That's enough?
DL6ER
January 29, 2024, 6:40pm
6
jockesve:
That's enough?
Yes. And thanks for the log file.
Interestingly your log shows an issue I thought has been fixed a long time ago, but it appears
pi-hole:development-v6
← pi-hole:fix/resolver
opened 08:03PM - 15 Dec 23 UTC
# What does this implement/fix?
More recent Pi-hole installations may not be … using `127.0.0.1` in `/etc/resolv.conf` but something like `192.168.0.1` or even `9.9.9.9`. So far, FTL uses a hack that ensures that - whatever is set in `resolv.conf` - we are always enforcing the use of FTL as DNS resolver when doing internal name lookups.
This is meaningful as external servers would very likely have no idea about the internal network structure and could not provide useful answers. Assuming the router is used in typical at-home deployments, it may still work (partially, locally defined records would not be available, for instance) but if the system is even using an external server such as Quad9, no answer will be available.
When switching from `glibc` to `musl` we lost the hack FTL has been using for years to temporary change the resolver used by the C library as `musl` does not care about the `_res` datastructure *at all* (they only add it for ABI compatibility reasons) and simply always reads `/etc/resolv.conf` itself for each query. As we - quite obviously - do not want to interfere with the system and change `/etc/resolv.conf` for each name lookup, we have to stop using the library-provided `getnameinfo()` function and implement a tiny DNS resolver ourselves. This is done in this PR. The new implementation ensure we are always asking FTL on the configured DNS port without relying on any special library behavior.
This PR is the follow-up on https://github.com/pi-hole/FTL/pull/1809 and is the final fix for this bug reported [on Discourse](https://discourse.pi-hole.net/t/dashboard-nur-noch-ips-unter-clients/66690).
---
**Related issue or feature (if applicable):** N/A
**Pull request in [docs](https://github.com/pi-hole/docs) with documentation (if applicable):** N/A
---
**By submitting this pull request, I confirm the following:**
1. I have read and understood the [contributors guide](https://docs.pi-hole.net/guides/github/contributing/), as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1)
5. I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
## Checklist:
- [x] The code change is tested and works locally.
- [x] I based my code and PRs against the repositories `developmental` branch.
- [x] I [signed off](https://docs.pi-hole.net/guides/github/how-to-signoff/) all commits. Pi-hole enforces the [DCO](https://docs.pi-hole.net/guides/github/dco/) for all contributions
- [x] I [signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) all my commits. Pi-hole requires signatures to verify authorship
- [x] I have read the above and my PR is ready for review.
is still in the reviewing process.
Please try running
pihole checkout ftl fix/resolver
and see if this fixes the issue you are seeing.
1 Like
Big thanks, issue solved immeditely!
1 Like
DL6ER
January 30, 2024, 6:14pm
8
The fix has passed review process and is now included in development-v6
. You should go back over there to continue receiving further updates. Thanks for confirming that this PR solved the issue for you. One could only assume that this confirmation is what suddenly made the review process going again
1 Like