Unbound refuses to serve DNS records for DHCP leases with underscores

[bugfixin]

I have several DHCP clients that use hostnames with underscores which worked on an older version of OPNsense (~6+months ago? unfortunately I don't have great records there).

Now, unbound logs the error "dhcpd leases: XXX_XXX not a valid hostname, ignoring"

I understand that some RFCs advise against this or even forbid it, but there are many environments where this is de facto required. I don't think it's the place of software to police adherence to RFCs

Is there a way to force the records to be added?

[Patrick M. Hausen]

It's the way of software to conform to RFCs. Always.

[bugfixin]

So why is it that I can add DNS records to virtually any DNS software with underscores in it, but not in this case. Media players play noncompliant files all the time. even in networking, flags are changed, things are played with all the time. If anything should balk at hostnames with underscores, shouldn't it be DHCPD instead of unbound?

This post isn't for arguing about RFCs, it's asking how do I tell unbound to do it anyway?

[bugfixin]

I was able to edit unbound_watcher.py at /usr/local/opnsense/scripts/dhcp/unbound_watcher.py to make

Code: [Select]

hostname_pattern = re.compile("(?!-)[A-Z0-9-_]*(?<!-)$", re.IGNORECASE). This allows unbound to serve the records properly.

Relevant commits:
https://github.com/opnsense/core/commit/02aae56f05f313e7a5bc59d1e2551864dbea9a12
https://github.com/opnsense/core/commit/2b89ff975f5f0e41c5edec9f3b6cc70967b38db8

FWIW I believe that this should be modified to DNS name rather than Host name, as DNS names allow underscores and there are plenty of real-world scenarios that this breaks. As this behavior was only changed 3 weeks ago, I expect more folks to be affected over time.

[cookiemonster]

I've just updated my firewall from 22.7.11 to 23.1. today and I can see the change. The underscore was allowed prior to the update.

Code: [Select]

Date,Severity,Process,Line
2023-07-14T10:09:35 Warning unbound dhcpd leases: Honor_6X not a valid hostname, ignoring
2023-07-14T10:09:20 Warning unbound dhcpd leases: Honor_6X not a valid hostname, ignoring
2023-07-14T10:09:18 Warning unbound dhcpd leases: Honor_6X not a valid hostname, ignoring
2023-07-14T10:08:38 Warning unbound dhcpd leases: Honor_6X not a valid hostname, ignoring
2023-07-14T10:08:26 Warning unbound dhcpd leases: Honor_6X not a valid hostname, ignoring
2023-07-14T10:06:52 Warning unbound dhcpd leases: Honor_6X not a valid hostname, ignoring
2023-07-14T10:05:55 Warning unbound dhcpd leases: Honor_6X not a valid hostname, ignoring
2023-07-14T10:05:53 Warning unbound dhcpd leases: Honor_6X not a valid hostname, ignoring
2023-07-07T09:57:10 Notice unbound dhcpd expired Honor_6X @ 192.168.5.179
2023-06-21T11:04:34 Notice unbound dhcpd expired Honor_6X @ 192.168.5.179
2023-06-19T19:56:49 Notice unbound dhcpd expired Honor_6X @ 192.168.5.179
2023-06-16T08:19:50 Notice unbound dhcpd expired Honor_6X @ 192.168.5.179
2023-06-14T08:09:56 Notice unbound dhcpd expired Honor_6X @ 192.168.5.179I'll ask on github logging it as a bug, which sounds like it isn't one if previous behaviour was against RFCs, if we can have the non-compliant behaviour back.