Bug #16646
openpfSense hostname/domain not added to /etc/hosts or DNS Resolver if "LAN" interface has no IPv4 or IPv6 configuration
0%
Description
Problem¶
There is some non-obvious logic controlling if/when pfSense registers the device's hostname in DNS, and this logic fails if the physical interface that pfSense deems to be the LAN has no IPv4 or IPv6 configuration.
I run into this problem when setting up a bridge interface to functionally be my LAN, enabling IPv4 on that, and disabling it on the individual member physical interfaces (one of which is the physical interface called "LAN"). /etc/hosts will no longer contain an entry for pfSense's configured FQDN (hostname.domain in General Setup page), and I assume this is also why Unbound stops resolving that FQDN.
But it turns out that even without a bridge, simply having the physical interface called "LAN" configured with no IPv4 or IPv6 causes this issue, even if some other physical interface is configured with IPv4 to function as the LAN.
This behavior is not obvious, and it seems like a bug (or at least the documentation is misleading/incomplete).
Versions and Hardware¶
I experienced this with both pfSense Plus 25.11-RELEASE on a Netgate 6100, and pfSense 2.8.1-RELEASE on a pfSense VK-T40E4.
Documentation Lacking¶
The DNS Resolver has an Advanced setting called "Disable Auto-added Host Entries", with a description that says "By default, the primary IPv4 and IPv6 addresses of this firewall are added as records...". There is no explanation given for what constitutes "primary" IPv4/IPv6 addresses. Also is "addresses" plural because there are multiple protocols mentioned (IPv4 and IPv6), or is it plural because it's possible for there to be multiple IPv4 addresses and multiple IPv6 addresses?
Workaround¶
A workaround is to explicitly add a host override under the DNS Resolver settings, but this is not ideal because it adds another hardcoded entry of the router's IP to the configuration, and one that will likely be forgotten by the administrator whenever changing the LAN IP or subnet.
Proposed Fixes¶
One easy (I think) improvement to this situation (albeit not completely a fix) would be to support having the DNS Resolver's host overrides refer symbolically to interfaces' addresses instead of having to hardcode them.
But I think a proper fix would involve making the DNS Resolver configurable to return either:- the IP of an explicitly chosen interface (regardless of which interface the DNS query was received on), or
- the IP of the interface on which the DNS query was received, or
- not resolve it at all (this setting already exists, "Disable Auto-added Host Entries").
(This setting should probably live on the DNS Resolver's General Settings page, and the existing "Disable Auto-added Host Entries" setting moved there from Advanced Settings.)
An even more flexible/powerful solution would be if each interface on which DNS is listening could independently be configured to return either:- the IP of an explicitly chosen interface (this being a per-interface setting, there is no need for a per-interface equivalent to # 2 above), or
- not resolve it at all (i.e. a per-interface equivalent of the existing "Disable Auto-added Host Entries" setting).
(As above, this setting should probably live on the DNS Resolver's General Settings page, and the existing "Disable Auto-added Host Entries" setting under Advanced Settings eliminated in favor of this new per-interface setting.)
Updated by cemysce . about 18 hours ago
I believe my proposed fixes would also address #7680.
Updated by cemysce . about 17 hours ago
Note that above, wherever I mentioned /etc/hosts missing the router's own hostname entry, /var/unbound/host_entries.conf was also missing it.
Updated by cemysce . about 3 hours ago
Another thing to note, this primary LAN interface is also what pfSense creates an automatic anti-lockout firewall rule for, assuming you don't disable that setting. So another possible solution (though not as useful/versatile as the above proposals) would be to have someplace in the UI to explicitly choose what the primary LAN interface is, so that it (and not what pfSense decides is primary) can benefit from these features (anti-lockout rule, DNS registration of router's hostname, etc.).