2026-04-04 22:00:00.687 ERROR DNS compression pointer out of bounds: 932
2026-04-04 22:00:00.687 ERROR Trying to copy a NULL (R) string in ngethostbyname() (/app/src/resolve.c:452)
2026-04-04 22:00:00.687 WARNING Resolved PTR "DDD.CCC.BBB.AAA.in-addr.arpa" on 127.0.0.1#53 (UDP) with status NoError (0): answer 0 (PTR "DDD.CCC.BBB.AAA.in-addr.arpa" => "(null)") is invalid
2026-04-04 22:00:00.687 WARNING Host name of client "AAA.BBB.CCC.DDD" => (null) contains (at least) one invalid character at position 0
2026-04-04 22:00:00.688 WARNING Trying to free NULL pointer in ngethostbyname() (/app/src/resolve.c:474)
2026-04-04 22:21:38.995 INFO Received 8/8 valid NTP replies from fritz.box
2026-04-04 22:21:38.996 INFO NTP time offset: 1.639026e+00 ms (excluded 1 outliers)
2026-04-04 22:21:38.996 INFO NTP round-trip delay: 3.329686e-01 ms (excluded 1 outliers)
Interestingly, this
2026-04-04 22:00:00.687 WARNING Host name of client "AAA.BBB.CCC.DDD" => (null) contains (at least) one invalid character at position 0
exists every hour. Therefore not sure why
this is logged now only (assuming this log entry is the reason for the entry on the diagnosis page)
the diagnosis page shows nothing (so one could actually 100 % be sure what's wrong)
The "DNS compression pointer out of bounds" and "invalid character at position 0" errors point to a specific device on your network sending malformed PTR records. The Shelly device name you mentioned is almost certainly the culprit.
Fritz!Box device hostnames are registered in your local DNS via mDNS and DHCP, and Fritz!Box tends to include non-ASCII characters or special characters in device names if you've named them in German or another language with umlauts (ä, ö, ü, etc.). When Pi-hole's FTL receives a PTR response for that device's IP with an invalid character at position 0 of the hostname label, it logs the error and cannot parse the hostname at all.
The empty diagnosis entry is a separate issue - when FTL tries to format the diagnostic message but the hostname string is null (because parsing failed), the message body ends up blank. This is a display bug in how FTL renders diagnostic entries when the associated data is null.
To fix the actual DNS errors:
Rename the Shelly device in Fritz!Box to use only ASCII characters (a-z, 0-9, hyphens). Remove umlauts or special characters from the device name.
If you cannot rename it (or it's a Fritz!Box-assigned name from DHCP that you cannot control), add a static local DNS PTR record in Pi-hole under Settings > DNS > Local DNS Records to override the bad reverse lookup. Map the Shelly device's IP to a clean ASCII hostname.
After doing either of these, the hourly FTL errors should stop. The empty diagnosis entry should also clear once there is no null string triggering it.
In fact there are many other clients with a hostname containing German umlauts (ä / ö / ü). Always have been, for years. No idea why at all (probably since some Pi-hole update a few months ago, maybe even since v6 which I upgraded to very late) and why only for that one single hostname/client Pi-hole is complaining.
I had that feeling, as the response was a typical LLM style text.
Anyway, since the local record no more hourly FTL log entries related to this anymore.
Debug token still oversized, contains way too much privacy related information and you did not change anything in the last years on that unfortunately. Therefore when really urgently needed I always parse through it, filter everything I don’t want to share with anyone manually and upload it then - which costs me 1/2 hour at least, sometimes even more. On the other hand, there were cases I provided one and it was not even read, instead it kind of timed out (automatic deletion after what, 48 hours?).
So in this case I tend to just go with the „AI provided solution“ for now.
Odd that you trust the software to handle your DNS and gather all your network info, but you don’t trust a debug token to the people who wrote that same code. If they were trying to sift through your private info, they could easily do it without your consent since you already have their software running.
Pi-Hole runs locally, the debug token(actually it’s a massive log file, „token“ is just the indicator of that log file) leaves the local network and gets uploaded to the (some kind access restricted part of the) internet.
Pointed out the excessive log content years ago, no improvements so far, if urgently needed I have my workaround (pre-filtering before uploading).
If that would be true, I‘d consider stop using Pi-Hole. But afaik that’s not true anyway.
Now diagnosis page is showing the empty HOSTNAME issue again. According to FTL log this time for another client, also containing an umlaut (ö in this case). Same story, every hour. I can't edit the hostnames in the router and setting all of them up in https://pi.hole/admin/settings/dnsrecords would be crazy. --> Workaround after spending a lot of time: created local DNS records.
I'm wondering why
does the diagnosis page show an empty message column
does FTL discover only one "problematic" (in my opinion handling an umlaut should not be one) one by one
is FTL bringing this up now when it did not in the past (some umlaut hostnames are older than Pi-Hole in my network)
Your opinion in this case is sadly incompatible with the reality of the standard requirements for hostnames.
Unless they are being translated to punycode (as specified by rfc5890) by the fritz box (unlikely), then they are simply not valid hostnames if they have non-ascii characters. If the fritz-box does not have that capability, then the solution is to simply stop naming them with invalid characters.
A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.).
You have a history of performatively demonstrating that you have no interest in providing the information that the Pi-hole team require to be able to diagnose your exact problem and provide help. Unless you are going to change your mind about that, then I would suggest as a next step at least try correcting the domain names on your network as they may well be a contributing cause of the problem.
I don’t know if FRITZ! is complying with the RFC or not - or if it’s a bug in FRITZ!OS. But I can tell I have other hostnames with umlauts that are correctly transformed (like „…-Tür.fritz.box“ is resolved as „…-tuer.fritz.box“ and only this single hostname is reported for the IP address by nslookup, only one line).
That’s not true. I can provide the necessary information.
It's entirely possible that the hostnames are being transformed by the devices before even being sent to the fritz box. This would be OS dependent and explain why it is happening with some devices but not others. If there are devices that are sending umlauts in their host name that you are able to rename without umlauts, it would probably be best to do so.
It's also possible that the Fritzbox transforms umlauts to ASCII conform name or anyhow involves itself in that process. The Fritzbox is the only "german" device that as a policy to work with that special characters.
But it does not explain why it works on one device and doesn't on another. Anyhow. Imagine kyrillic or chinese characters. ASCII has its meaning and is a sensefull definition.
To me I would simply avoid german umlauts in naming of devices to avoid these kind of conflicts. Be pragmatic.
