Currently running Pi-Hole 6.1. I noticed a strange message in the diagnostics section after startup.
Host name of client 10.0.200.xx => "myhostname.(none)" contains (at least) one invalid character (hex 6f) at position 0
but everything seems to be working as it should. Is this something to worry about? How can I prevent this message appearing after every restart?
This observation seems similar to Host name of client xxx => contains (at least) one invalid character at position 0 - #91 by DL6ER, where DL6ER seems to wait for user feedback.
Could you please enable DHCP logging and share DHCP related lines from /var/log/pihole/FTL.log once the issues reoccurs?
sudo pihole-FTL --config dhcp.logging true
I do not use any DHCP functions in Pi-Hole so is this relevant? DHCO[6] is handled by my router/firewall (NetGate 56100 running pfSense). I have two identically configured Pi-Hole servers which front-end my 2 main (authoritative) DNS servers. I use them for selected clients only to provide ad-blocking.
If your Pi-hole doesn't handle DHCP, then enabling DHCP logging won't be helpful, as your issue is different from the one I've linked above.
'hex 6f' would be an o, which is different from the m you are quoting as the first character in your name, but then both would be valid characters, and my guess would be that you'd have made up that name instead of quoting a real one.
The brackets ( ) would be the actual invalid characters in your domain name (unless you've made those up as well).
Try if removing them from the name in your router's DHCP server would fix your issue.
The FQDN of the server where pihole is running, as returned by 'hostname' is 'glamdring.home.thejenkinsfamily.org.uk'. I used 'myhostname' in the example for simplicity. The name 'glamdring.(none). does not come from my DHCP server (it doesn't know anything about this host nor is it involved at all in name resolution) nor from my primary DNS servers; it is a string derived/constructed purely by pihole. Hex 6f is ascii 'o' (lowercase O). Pi-hole seems to have its knickers in a twist somewhere...
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 if you run your Pi-hole as a Docker container:
docker exec -it <pihole-container-name-or-id> pihole -d
where you substitute <pihole-container-name-or-id> as required.
Done. Token is https://tricorder.pi-hole.net/GWKUmqgd/
Pi-hole wouldn't answer any DNS requests itself, unless it has been explicitly configured to do so.
Your debug log shows such local CNAME definitions only, and none of them matches the offending domain.
To verify, let's check how Pi-hole deals with a reverse lookup.
Please share the output of:
nslookup <ip.of.offending.device> 10.0.200.37
Please monitor /var/log/pihole/pihole.log for respective log entries, e.g. via Tools | Tail log files | pihole.log, and share those lines as well.
Okay, note that the 'problem' host is the actual Pi-Hole host itself (glamdring/10.0.200.37). I don;t see these messages for any other hosts. On my other Pi-Hole server I get the same message for its IP address. Here are the query results directly against one of my authoritative servers and against the pihole server:
$ nslookup 10.0.200.37 10.0.200.10
Server: 10.0.200.10
Address: 10.0.200.10#53
37.200.0.10.in-addr.arpa name = glamdring.lan.thejenkinsfamily.org.uk.
$ nslookup 10.0.200.37 10.0.200.37
Server: 10.0.200.37
Address: 10.0.200.37#53
37.200.0.10.in-addr.arpa name = glamdring.\(none\).
And the relevant lines from pihole.log for that query:
2025-05-31 15:28:16.651 query[PTR] 37.200.0.10.in-addr.arpa from 10.0.200.40
2025-05-31 15:28:16.651 config 37.200.0.10.in-addr.arpa is <PTR>
Interestingly after my most recent DNS restart I get the message for all 4 of the local pihole server's addresses:
Host name of client fe80::21c:42ff: fe1b: 8bf4 => "glamdring. (none)" contains (at least) one invalid character (hex 67) at position 0
Host name of client fd00::37 => "glamdring. (none)" contains (at least) one invalid character (hex 67) at position 0
Host name of client 2a0e: cb01:92:77ee::37 => "glamdring. (none)" contains (at least) one invalid character (hex 67) at position 0
Host name of client 10.0.200.37 = "glamdring. (none)" contains (at least) one invalid character (hex 67) at position 0
So whatever the issue is it is localised to pihole...
This line indicates that Pi-hole's DNS server has indeed been configured with a name for 10.0.200.37.
Or to the machine that's hosting your Pi-hole.
Run from that machine, please share the output of:
cat /etc/hosts
Nothing weird or fancy about it. Just a vanilla Centos10 server running Pi-Hole in a docker container.
chris@glamdring:~$ cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
Since we are dealing with the hostname of the device that runs Pi-hole, Pi-hole may also source that from the kernel's uname structures.
On Linux systems, that commonly would be the content of
cat /etc/hostname
Also, what's the output of:
hostname
Againb, as one would expect:
chris@glamdring:~$ cat /etc/hostname
glamdring.home.thejenkinsfamily.org.uk
chris@glamdring:~$ hostname
glamdring.home.thejenkinsfamily.org.uk
Please set the environment variables:
FTLCONF_debug_queries: true
FTLCONF_debug_resolver: true
and restart the container.
Then, please have a look at the file /var/log/pihole/FTL.log and search for the message "Host name of client...".
Copy the related (maybe ~ 50) lines above this in the log and post them here.
I set the environment variables as part of the container creation as follows, is this okay?
sudo docker create \
--name=pihole \
--hostname=glamdring \
--restart=unless-stopped \
-e TZ=Europe/London \
-v "/pihole/etc-pihole:/etc/pihole" \
-v "/pihole/etc-dnsmasq.d:/etc/dnsmasq.d" \
--dns=10.0.200.10 --dns=10.0.200.15 \
--dns=fd00::10 --dns=fd00::15 \
--network=host \
-e VIRTUAL_HOST="pihole1.home.thejenkinsfamily.org.uk" \
-e PROXY_LOCATION="pihole1.home.thejenkinsfamily.org.uk" \
-e FTLCONF_dns_upstreams="10.0.200.10;10.0.200.15;fd00::10;fd00::15" \
-e FTLCONF_debug_queries=true \
-e FTLCONF_debug_resolver=true \
pihole/pihole:latest
I then recreated the container, ran nslookup 10.0.200.37 10.0.200.37 and examined /var/log/pihole/FTL.log. There was no string 'Hiost name of client', or anything similar but I could see the entries relevant to my query:
2025-05-31 19:22:17.590 BST [55M] DEBUG_QUERIES: Generating PTR record (0xffffaba21aa0): 37.200.0.10.in-addr.arpa -> glamdring.(none)
2025-05-31 19:22:17.590 BST [55M] DEBUG_QUERIES: **** new UDP IPv4 query[PTR] query "37.200.0.10.in-addr.arpa" from enp0s5/10.0.200.40#54251 (ID 298, FTL 138166, src/dnsmasq/forward.c:1897)
2025-05-31 19:22:17.590 BST [55M] DEBUG_QUERIES: Set global cache status to 0
2025-05-31 19:22:17.590 BST [55M] DEBUG_QUERIES: 37.200.0.10.in-addr.arpa is not known
2025-05-31 19:22:17.591 BST [55M] DEBUG_QUERIES: Checking if "37.200.0.10.in-addr.arpa" is in antigravity (exact): no
2025-05-31 19:22:17.591 BST [55M] DEBUG_QUERIES: Checking if "37.200.0.10.in-addr.arpa" is in gravity (exact): no
2025-05-31 19:22:17.591 BST [55M] DEBUG_QUERIES: DNS cache: PTR/10.0.200.40/37.200.0.10.in-addr.arpa is not blocked (domainlist ID: -1)
2025-05-31 19:22:17.591 BST [55M] DEBUG_QUERIES: **** got cache reply: <PTR> is 37.200.0.10.in-addr.arpa (ID 298, src/dnsmasq/rfc1035.c:1925)
2025-05-31 19:22:17.591 BST [55M] DEBUG_QUERIES: DNS cache: PTR/10.0.200.40/37.200.0.10.in-addr.arpa -> CACHE, no expiry
2025-05-31 19:22:17.591 BST [55M] DEBUG_QUERIES: Set reply to RRNAME (6) in src/dnsmasq_interface.c:2360
The lines before this seemed to be totally unrelated (handling other unrelated queries).
@rdwebdesign is the log snippet helpful? if not do you need anything else?
I'm not sure if we will need more info, but currently we are fixing another bug in FTL and we need a little more time before looking into this.
There is an open issue in Github with the same symptoms: Diagnosis shows errors about invalid hostnames incorrectly · Issue #2452 · pi-hole/FTL · GitHub
After we release the fix for the other bug we will try to understand what is causing the wrong hostname detection.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.