Static DHCP assignment instructions suggest underscores are not supported in hostname, but they work

[AnotherLuckyGuy]

Versions

• Pi-hole: 6.4.3
• Web: 6.6
• FTL: 6.7

Platform

• OS and version: Linux Mint 22.3, Raspberry Pi Bookworm

• Platform: Intel, Raspberry Pi

Expected behavior

Personally I like the behavior. Not sure if there's a good reason not too support the underscore character in hostnames or not. The on-screen help shouldn't suggest they aren't supported if they are though, nor highlight them in red. Or perhaps the help text should just be updated to suggest they violate the standard and might cause problems so use at your own risk.

Actual behavior / bug

Note blue and red highlights

nslookup TPLinkCam_6FAC

Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: TPLinkCam_6FAC.lan
Address: 192.168.1.53

Steps to reproduce

Steps to reproduce the behavior:

1. Add static lease with underscore in name
2. It gets assigned
3. Confirm in list of active leases
4. Confirm with nslookup command

Debug Token

• URL:

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

[PromoFaux]

To quote @rdwebdesign over on reddit

The validation function considers these 44 hostnames as invalid, because they contain the underscore _ character.

If you check the standards defined by RFC-952 and RFC-1123, you will see this character is not allowed in hostnames. Some systems still allows it (probably for compatibility reasons with older systems), but this is not officially part of the standard.

Generally, the hyphen character (-) is recommend to separate words in cases like this.

References:

https://serverfault.com/questions/397234/the-use-of-the-underscore-in-host-names

https://www.rfc-editor.org/info/rfc952/

https://www.rfc-editor.org/info/rfc1123/

[AnotherLuckyGuy]

Thanks @PromoFaux. If it's intentional that pihole allows the underscore to be used despite violating the standard, the help text should say something to that effect. Saying "Only letters, digits, hyphens and dots are allowed in hostnames." but then allowing the underscore (and perhaps other characters?) certainly appears to be a bug even if it's intentional. I'm not personally aware of what problems it might cause allowing underscores - I haven't noticed anything on my home network - but if it does potentially create problems the help text should be clear that it's a user-error intentionally deviating into unsupported territory vs a pihole bug.

Perhaps "Standards dictate only letters, digits, hyphens and dots are allowed in hostnames. Hostnames that include non-standard characters such as an underscore will be highlighted in red and may cause issues on your network."

[yubiuser]

If it's intentional that pihole allows the underscore to be used

What do you mean by "allows"? Should it reject the input when clicking "Save & Apply"? It already marks invalid hostnames with red background and the page contains the help text.

[AnotherLuckyGuy]

@yubiuser that's just it... while it does highlight them in red after the fact, it doesn't reject the input when using the Advanced settings, which of course was the only way to add/edit items in v6 for quite a while. I can edit the existing items or add new ones without issues saving them. Your comment made me realize that I cannot edit/add them by clicking and editing them in the table as I used to in v5... attempting to save changes there now does give an error message.

So since allowing underscores in the names isn't an intentional feature, a save on the Advanced Settings should fail as well.

[yubiuser]

It's actually more complicated. Pi-hole's DNS engine FTL is based on dnsmasq which does not reject invalid ("underscore") hostnames. So when we mark it as "invalid" you can't save when you use the table input fields. But it's not rejected when you use the advanced settings input box as this uses plain dnsmasq config style.
So the web interface enforces adherence to standard, but advanced users can input all syntax dnsmasq accepts in the input box.

[AnotherLuckyGuy]

@yubiuser thanks for the clarification. I think my original suggestion of correcting the on-screen instruction still holds merit then.

Instead of instructional text on the page saying "Only letters, digits, hyphens and dots are allowed in hostnames." but then allowing the underscore (and perhaps other characters?) , perhaps "RFC-952 and RFC-1123 standards dictate only letters, digits, hyphens and dots are allowed in hostnames. Hostnames that include non-standard characters - possible through Advanced Settings - will be highlighted in red and may cause issues on your network."

[yubiuser]

RFC-952 and RFC-1123 standards dictate only letters, digits, hyphens and dots are allowed in hostnames. Hostnames that include non-standard characters - possible through Advanced Settings - will be highlighted in red and may cause issues on your network."

Only downside I see is the length of the text. We could put it in "Advanced Settings help" but this is already a wall-of-text