Host name of client 203.0.113.41 => "dns-vm-1.(none)" contains (at least) one invalid character (hex 28) at position 10

Help
1

[Domain name and IP address have been sanitized for privacy.]

Debian 12, bare metal, proxmox vm

I have my hostname and domain name set properly in /etc/hosts:

127.0.0.1 localhost
127.0.1.1 dns-vm-1.example.com dns-vm-1
203.0.113.41 dns-vm-1.example.com dns-vm-1

and /etc/hostname:
dns-vm-1

% hostname -f
dns-vm-1.example.com
% hostname -s
dns-vm-1
% hostname -d
example.com
% dnsdomainname
example.com

When dns.piholePTR is set to HOSTNAMEFQDN, Pi-hole 5 and 6 are using NIS/YP domain name / kernel.domainname to set the domain name for the pi-hole host. NIS/YP domain name is obsolete and should not be used. You can set kernel.domainname, but it does not survive restarts. After every restart you get this:

% sysctl kernel.domainname
kernel.domainname = (none)
% domainname
(none)
% hostname -y
hostname: Local domain name not set
% nisdomainname
nisdomainname: Local domain name not set
% ypdomainname
ypdomainname: Local domain name not set

This causes errors to be reported if the dns.piholePTR is set to HOSTNAMEFQDN:

Host name of client 203.0.113.41 => "dns-vm-1.(none)" contains (at least) one invalid character (hex 28) at position 10

There are no such errors if dns.piholePTR is set to HOSTNAME.

2

As a DNS server, Pi-hole doesn't set NIS/YP name resolution.

More specifically, dns.piholePTR doesn't write NIS domain names.
It controls how Pi-hole populates PTR records for the IPs of the machine it runs on, i.e. it may be reading host information as provided by the OS (once during service startup, so changing dns.piholePTR may trigger a service restart).

Assuming that's a warning from Pi-hole diagnosis, what command or action triggered that warning?

I am unable to recreate your issue on my Pi-hole (click for details) 
~$ grep made.up /etc/hosts
192.168.1.53 nanopi.made.up nanopi

~$ domainname
(none)

~$ dnsdomainname
made.up

$ hostname -f
nanopi.made.up

~$ sudo pihole-FTL --config dns.piholePTR HOSTNAMEFQDN
HOSTNAMEFQDN

dig +short -x 192.168.1.53 @192.168.1.53
nanopi.fritz.box.

Now, fritz.box is my local/search domain as propagated by my router, so that is indeed a correct FQDN.
Obviously, the difference here is that my Pi-hole is sourcing the FQDN from DNS, not via OS calls, which would be attributable to me using a private range IP.

Changing that /etc/hosts entry to my DynDNS IP and restarting pihole-FTL results in:

$ dig +short -x <public.ip> @192.168.1.53
nanopi.made.up.

whereas a public reverse lookup for that same IP would return something like

dig +short -x <public.ip> @8.8.8.8
i22F42F41.compunet.com.

So in my case, Pi-hole has read the name as defined in /etc/hosts, as expected.

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.

3

Thank you for your good work and for trying to help me.

I understand that pi-hole doesn’t write NIS domains. I am trying to resolve the error message that pi-hole diagnosis lists, anytime pi-hole is started. I suspect that pi-hole was trying to pull the domain name from NIS records, which after restart, revert to “(none)” - exactly like what is in the diagnosis error message.

token URL:

https://tricorder.pi-hole.net/u5MJLAbT/

Please note that if in /etc/pihole/pihole.toml, I change
domain = ""
to
domain = "example.com"
then my local IPs resolve to
dns-vm-1.example.com.example.com

8

Hmm, all of my Linux systems (LMDE, Debian, Armbian, RPi OS) would always return '(none)' for domainname.

I wonder why recreating equivalent entries in my /etc/hosts does not trigger your observation?

We are currently investigating those circumstances, so thanks for the heads up.
Your debug log contains a copy of your /etc/resolv.conf.
Could you share your /etc/hostname, /etc/host.conf and /etc/nsswitch.conf as well?

Meanwhile, you could try if the following steps would address your observation:
a) Remove your dns-vm-1.example.com FQDN aliases from /etc/hosts
b) Set dns.domain to your local/search domain, e.g. via

sudo pihole-FTL --config dns.domain example.com

c) Set dns.expandHosts to true, e.g.

sudo pihole-FTL --config dns.expandHosts true

Your debug log shows that your router is indeed propagating a public domain as local/search domain (and I can also see that you are indeed using private range IPs in your /etc/hosts, though you've posted those here as public range IPs).

If you use a public domain without setting dns.domain, you should be aware that you may get unexpected resolution results, as any request for a record type that your Pi-hole would not hold a definition for would be forwarded upstream.
E.g. this could result in Pi-hole returning a private range IPv4 for an A request, while an AAAA request could return a public IPv6.
You may already be aware of this, as your debug log indicates you've defined IPv4 as well as IPv6 addresses at least for your dns-vm-1, but you should note that this may also affect any other record type as well (e.g. MX).

On the other side, once you set dns.domain, Pi-hole would never forward matching DNS requests upstream, probably preventing public resolution even if you'd have wanted it.
And as your debug log shows that your using bind's named as Pi-hole's only upstream, you may want to configure Pi-hole's Conditonal Forwarding for your example.com to your named, so local definitions from named would still resolve.

And independently from your observation, as you run named:
Note that unlike a full DNS resolver, pihole-FTL/dnsmasq does not support the concept of views (where DNS replies may differ based on the
requestor's IP).
If your named would take advantage of those, you may have to consider changing the order of your DNS resolution chain, as having Pi-hole sit in front of named would hide the original request source.

All things considered, it may be easier to consider just using one of the domains intended for private networks (e.g. internal, lan or home.arpa) for private range communication, and keep your public domain strictly with public DNS.

15

Thanks for looking into this, and if this edge case is helpful in resolving a hidden issue, then I’m glad for that.

% cat /etc/hostname
dns-vm-1

% cat /etc/host.conf
multi on

% cat /etc/nsswitch.conf
# /etc/nsswitch.conf
# Example configuration of GNU Name Service Switch functionality.
# If you have the \`glibc-doc-reference' and \`info' packages installed, try:
# \`info libc "Name Service Switch"' for information about this file.
passwd:         files
group:          files
shadow:         files
gshadow:        files
hosts:          files dns
networks:       files
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files
netgroup:       nis

Yes, as I mentioned, domain name and IP addresses have been sanitized for privacy here (but not in the pi-hole debug report sent to you).

Also, as I mentioned, if in /etc/pihole/pihole.toml, I change
domain = ""
to
domain = "example.com"
then my local IPs resolve to (for example)
happy-little-threadripper.example.com.example.com

For the record, the “public domain” that I use, is owned/registered by me, and is used exclusively on my LAN. Unfortunately, do to the extensive number of hosts with SSL certificates that the hosts employ, using generic lan domains is not an option.

My local DNS servers have authoritative DNS zones and reverse PTR zones (via bind9) for that domain that are not available on the internet, and pi-hole is not supposed to be an authoritative DNS server for any IP in my setup (including it’s own IP).

If pi-hole was properly non-authoritative as I have (attempted to) set it, then it would follow proper procedure to get it’s FQDN from (upstream) DNS (bind9). If things were working as they should, then pi-hole does a PTR lookup for the LAN IP 203.0.113.41, and bind9 replies with the correct FQDN dns-vm-1.example.com. That’s what happens when I do a reverse IP lookup for any (other) host on my LAN. Pi-hole follows proper procedure, and retrieves the correct FQDN.

The only time it fails, is if I do a reverse PTR lookup (anywhere on my LAN) for 203.0.113.41 and 203.0.113.41 replies (incorrectly, non FQDN): “dns-vm-1.” If I do a reverse PTR lookup for 203.0.113.41 and 203.0.113.42 (my other local DNS server) replies (correctly, w/ FQDN): “dns-vm-1.example.com”.

The same issue is on the other DNS server on my LAN (which has an identical setup). The only time it fails, is if I do a reverse PTR lookup (anywhere on my LAN) for 203.0.113.42 and 203.0.113.42 replies (incorrectly, non FQDN): “dns-vm-2.” If I do a reverse PTR lookup for 203.0.113.42 and 203.0.113.41 (my other local DNS server) replies (correctly, w/ FQDN): “dns-vm-2.example.com”.

In this edge case, Pi-hole is inserting itself where it does not need to.

As I mentioned, I have my hostname and domain name set properly (following all best practices) in /etc/hosts:

127.0.0.1 localhost
127.0.1.1 dns-vm-1.example.com dns-vm-1
203.0.113.41 dns-vm-1.example.com dns-vm-1

and /etc/hostname:
dns-vm-1

% hostname -f
dns-vm-1.example.com
% hostname -s
dns-vm-1
% hostname -d
example.com
% dnsdomainname
example.com

I have my upstream authoritative DNS servers set properly (following all best practices, I’ve been doing this and more for three decades, I’m old - insert graybeard meme, shakes fist into the air).

The issue is pi-hole not following proper DNS resolution practices in the case where pi-hole is intended to be a recursive / caching DNS server (no authoritative DNS responsibilities) employing an IP blacklist.

It’s cool that pi-hole has other features, like DHCP and authoritative DNS - but I employ it exclusively for it’s ad-blocking / malware-blocking (and caching) capabilities. In this case, it should not be getting in the middle of, and not properly handling the resolution of it’s own assigned IP.

Thank you for your consideration. I love pi-hole!

16

Yes, that's understood from your previous reply, and the reason why I suggested to try removing dns-vm-1.example.com from your /etc/hosts.

But as you mention to manage local names via your named:

Would setting dns.piholePTR to NONE address your issue then?

sudo pihole-FTL --config dns.piholePTR HOSTNAMEFQDN

# - "NONE"
# Pi-hole will not respond automatically on PTR requests to local interface
# addresses. Ensure pi.hole and/or hostname records exist elsewhere.

For your specific case, above comments would suggest that reverse lookups will be dealt with by Pi-hole's upstreams, so it should be your named handling them.

17

You are right, the correct setting for my situation is:

doas pihole-FTL --config dns.piholePTR NONE

I (mis)understood NONE to mean that pi-hole would drop / reject any PTR request for private IP ranges, as opposed to passing PTR requests upstream.

Many thanks for your help troubleshooting this.

18

Re the (none) issue: Do not set domainname when the kernel replies with "(none)" by DL6ER · Pull Request #2620 · pi-hole/FTL · GitHub

19

Looks good! Perhaps it might make sense to revise the explanation for the “dns.piholePTR NONE” option so that dumb-dumbs like myself understand what it means more easily.

I (mis)understood NONE to mean that pi-hole would drop / reject any PTR request for private IP ranges, as opposed to passing PTR requests upstream.

Thank you so much for the work that you do, I really appreciate my pi-holes!