pfSense

Can you please bring some examples and facts from pfSense config files?

Could fix for the statically assigned hosts of each interface in services dhcp be as simple as this?

--- /etc/inc/system.inc 2011-08-27 21:34:19.000000000 0700
++ /etc/inc/system.inc.patched 2011-08-28 16:11:18.000000000 -0700
@ -253,7 +253,7 @
if(is_array($dhcpifconf['staticmap']) && isset($dhcpifconf['enable']))
foreach ($dhcpifconf['staticmap'] as $host)
if ($host['ipaddr'] && $host['hostname'])
$dhosts .= "{$host['ipaddr']} {$host['hostname']}.{$syscfg['domain']} {$host['hostname']}\n";
$dhosts .= "{$host['ipaddr']} {$host['hostname']}.{$config['dhcpd'][$dhcpif]['domain']} {$host['hostname']}\n";
}

if (isset($dnsmasqcfg['dhcpfirst']))

However, the dynamically assigned hosts may be more difficult and involved due to being handled by dhcpleases process.
The following may work for just assigning the domain name of a particular services dhcp interface. Such as 'LAN'.

--- /etc/inc/system.inc 2011-08-27 21:34:19.000000000 0700
++ /etc/inc/system.inc.patched 2011-08-28 16:11:18.000000000 -0700
@ -292,7 +292,7 @
if (file_exists("{$g['varrun_path']}/dhcpleases.pid"))
sigkillbypid("{$g['varrun_path']}/dhcpleases.pid", "HUP");
else
mwexec("/usr/local/sbin/dhcpleases -l {$g['dhcpd_chroot_path']}/var/db/dhcpd.leases -d {$config['system']['domain']} -p {$g['varrun_path']}/dnsmasq.pid -h {$g['varetc_path']}/hosts");
mwexec("/usr/local/sbin/dhcpleases -l {$g['dhcpd_chroot_path']}/var/db/dhcpd.leases -d {$config['dhcpd']['lan']['domain']} -p {$g['varrun_path']}/dnsmasq.pid -h {$g['varetc_path']}/hosts");
} else {
sigkillbypid("{$g['varrun_path']}/dhcpleases.pid", "TERM");
@unlink("{$g['varrun_path']}/dhcpleases.pid");

Maybe dhcpleases needs to accept a parameter list of ip address range and domain name pairs. Instead of just a statically provided domain name. Maybe provided via a config file or such...

Maybe just a tad bit of logic for using system domain when not specified in dhcp interface.

--- /etc/inc/system.inc    2011-08-29 07:02:35.000000000 -0700
+++ /etc/inc/system.inc.patched    2011-08-29 18:29:46.000000000 -0700
@@ -252,8 +252,11 @@
         foreach ($config['dhcpd'] as $dhcpif => $dhcpifconf)
             if(is_array($dhcpifconf['staticmap']) && isset($dhcpifconf['enable']))
                     foreach ($dhcpifconf['staticmap'] as $host)
-                        if ($host['ipaddr'] && $host['hostname'])
-                            $dhosts .= "{$host['ipaddr']}    {$host['hostname']}.{$syscfg['domain']} {$host['hostname']}\n";
+                        if ($host['ipaddr'] && $host['hostname']) {
+                            if ($config['dhcpd'][$dhcpif]['domain']) $dyndhcpifdomainname = $config['dhcpd'][$dhcpif]['domain'];    // Use Services DHCP Interface Domain Name
+                            else $dyndhcpifdomainname = $syscfg['domain'];                                    // Use System General Domain Name
+                            $dhosts .= "{$host['ipaddr']}    {$host['hostname']}.{$dyndhcpifdomainname} {$host['hostname']}\n";
+                        }
     }

     if (isset($dnsmasqcfg['dhcpfirst']))
@@ -291,8 +294,11 @@
         @touch("{$g['dhcpd_chroot_path']}/var/db/dhcpd.leases");
         if (file_exists("{$g['varrun_path']}/dhcpleases.pid"))
                 sigkillbypid("{$g['varrun_path']}/dhcpleases.pid", "HUP");
-        else
-            mwexec("/usr/local/sbin/dhcpleases -l {$g['dhcpd_chroot_path']}/var/db/dhcpd.leases -d {$config['system']['domain']} -p {$g['varrun_path']}/dnsmasq.pid -h {$g['varetc_path']}/hosts");
+        else {
+            if ($config['dhcpd']['lan']['domain']) $dyndhcpifdomainname = $config['dhcpd'][lan]['domain'];    // Use Services DHCP 'LAN' Interface Domain Name
+            else $dyndhcpifdomainname = $config['system']['domain'];                        // Use System General Domain Name
+            mwexec("/usr/local/sbin/dhcpleases -l {$g['dhcpd_chroot_path']}/var/db/dhcpd.leases -d {$dyndhcpifdomainname} -p {$g['varrun_path']}/dnsmasq.pid -h {$g['varetc_path']}/hosts");
+        }
     } else {
         sigkillbypid("{$g['varrun_path']}/dhcpleases.pid", "TERM");
         @unlink("{$g['varrun_path']}/dhcpleases.pid");

Yup, I hear ya.

Maybe by 2.1 someone could figure out how to do the dynamic hosts part per interface also, instead of just hardcoded to LAN interface.

Any updates on this? It also seems to be affecting unbound on 2.3.2-p1. Until this is fixed, perhaps removing the domain name field in the DHCP server settings would be appropriate? Or at least moving it to advanced settings such that dynamic DNS would use it but would not cause confusion otherwise.

Well nobody's assigned to it and it's a 5 year old ticket. Last few comments were from Chris and he works for Ubiquiti now, so I wouldn't hold my breath :/

I am having this same exact issue. Has there been any traction on this?

With Unbound and the newest release of pfSense ATM (2.3.3-RELEASE-p1 (amd64)) it isn't working for one of four interfaces.
Is there some way to manually edit the config in order to temporary override this problem?

I'm also experiencing this bug with 2.3.3-RELEASE (amd64) using Unbound and no BIND. LAN (renamed "LAN1") serves regular workstation clients with the pfSense system domain (lan.mydomain.co.za) while I use OPT1 (I renamed to "LAN2") interface as a subnet for local servers (srv.mydomain.co.za -- only accessible from LAN1). pfSense DHCP server on LAN2 overrides domain name and domain search list correctly, and this works as far as DHCP clients and the server are concerned... but the corresponding automatic DNS entries (in Unbound) for non-static DHCP leases use the system domain suffix regardless.

To clarify: if I have DHCP client computer "foo1-pc" on LAN1 then pfSense correctly resolves its address from name foo1-pc.lan.mydomain.co.za. The problem is if I connect "foo2-pc" to LAN2 (also running DHCP client) then pfSense resolves foo2-pc.lan.mydomain.co.za but not foo2-pc.srv.mydomain.co.za

(side note, connectivity is not the problem here, just DNS entries pulled from DHCP table: foo2-pc correctly gets an IP address on LAN2 subnet and its DNS entry correctly resolves to said IP LAN2 address -- the problem is just the DNS entry is part of the LAN1 subdomain)

However, I found that static DHCP leases on LAN2 don't have this issue! Once a static lease is entered from Status -> DHCP Leases for foo2-pc its DNS entry is "foo2-pc.srv.mydomain.co.za". This solves my issue, since I was going to allocate static leases to all servers anyway. But the fact that new servers connected to LAN2 subnet will not show up on LAN2 subdomain until they are assigned static leases is a nasty surprise bound to come up again for the next admin.

I don't know how tracert exactly works, but when using tracert it is resolving the "wrong" subdomain to the right one, as the subdomain assigned to the subnet in the DHCP server.

So if I ping host1, it will resolve to host1.lan.home.local instead of giving me an error because the host is associated with host1.otherlan.home.local.
With tracert its initially the same, it will resolve host1 to host1.lan.home.local, but when it reaches the destination network with subdomain otherlan.home.local it will show host1.otherlan.home.local.

I'd thought this would maybe help debugging.

Edit:

When I use nslookup to check the names, it will resolve both host1.lan.home.local and host1.otherlan.home.local to the same IP, but it prefers host1.lan.home.local since my own devices are in the lan.home.local network too. So nothing suprising there, but apparently it actually does tag the otherlan.local.home to the devices now, which didn't happen before.

is there an ETA on this one?

Unfortunately, it looks like it keeps getting kicked down the road a bit. This would be a really nice bit of polish for a release.

I just started a bounty thread on the pfSense forums:

https://forum.pfsense.org/index.php?topic=143579.0

Essentially what I like to be able to do is outlined in that above forum link. Here is an Imgur diagram of exactly what I like to do with all the domains and subdomains being handed out correctly by pfSense and resgistered in the DNS resolver correctly:

https://i.imgur.com/zB5kCTQh.jpg

That issue is planned for 2.5.0, but is it already available?

I've just tested the latest 2.5.0 development version, and I'm still facing the same issue.

I am still wishing this would get fixed as well. Not much traction on my bounty thread either.

Lynn Dixon wrote:

I am still wishing this would get fixed as well. Not much traction on my bounty thread either.

+1

Lynn Dixon wrote:

I am still wishing this would get fixed as well. Not much traction on my bounty thread either.

+1

Is this even still on the radar ? I saw it get pushed to 2.5

+1 on this as I am experiencing the same problem.

Confirmation that this fix is effectively targeted in 2.5 is highly appreciated

Added by NOYB NOYB over 8 years ago.

Since then there were 10 interactions with developers regarding the state of this ticket, however, no response on why it was moved and when it actually gets fixed.
It's been 8 years, and three years since I initially voted for this bug to be squatted.
Why isn't this being deleted if there's apparently no interest to fix this bug at all?

I believe this is a duplicate of another ticket that's been in here for a while, not readily seeing it so I'll leave this here.

Why is it actually an option in pfSense if it did not work for over 8 years now?

NOYB NOYB even made a usable fix to be merged for v2.1.
This is just retarded wth

Using insults and profanity will not convince anyone to speed up work, nor will it convince anyone you are correct.

Fixing this issue is nowhere near as simple as that patch implies. The DHCP server can be configured for one domain name per interface. The DHCP leases parsing daemon which maintains the DNS entries only supports a single domain name, not one per interface/subnet. That proposed solution would only work for the first interface, which would not be a proper solution. It will take a lot more coding to allow dhcpleases to map pool-specific domains to hosts.

The issue remains open because eventually we'd like to see it fixed. It has not been a priority, so when time is short, it gets moved along to future versions.

Wouldn't it be a good idea to just add a note somewhere near the option itself, that it doesn't work and probably will not work in the foreseeable future?
Googling and eventually finding this thread seems like something that could be easily tackled with just a simple comment.
Or just disable it alltogether until work is being done on this ticket?
Just not do anything at all about it seems a tad odd, since it just does not work but is presented as if it does, and has been known it does not work since over nine years now.

To be fair, it does at least hint to the fact on the setting description where it says:
"The domain in System > General Setup should also be set to the proper value."
Granted, the wording could be more clear.

bump
11 years later and still no fix?

I just ran into this bug and couldn't figure out why this was happening. It's really unfortunate that this is still outstanding after 11 years. Is there any chance that someone will fix this? Please? :-). Pretty please?

Jim Pingle wrote in #note-35:

Fixing this issue is nowhere near as simple as that patch implies. The DHCP server can be configured for one domain name per interface. The DHCP leases parsing daemon which maintains the DNS entries only supports a single domain name, not one per interface/subnet. That proposed solution would only work for the first interface, which would not be a proper solution. It will take a lot more coding to allow dhcpleases to map pool-specific domains to hosts.

The issue remains open because eventually we'd like to see it fixed. It has not been a priority, so when time is short, it gets moved along to future versions.

It does seem that it is at least partially able to work - if you make DHCP static entries, those will resolve as expected. So maybe the code that is being used there could be used for all of them, just not the static entries perhaps?

Ondrej Sala wrote in #note-39:

bump
11 years later and still no fix?

Allistah F wrote in #note-40:

I just ran into this bug and couldn't figure out why this was happening. It's really unfortunate that this is still outstanding after 11 years. Is there any chance that someone will fix this? Please? :-). Pretty please?

It seems that there is no need for a message in the web UI stating it is a known issue, and there has been no activity for years except for upping the target version.
There have been kind messages about this issue, there have been not so kind messages, there have been proposed fixes, and all those things have not changed anything.
I can't code properly myself, otherwise I'd be fiddling around with it since it's a nice feature to have.
I would say this issue is a wontfix.

I left pfSense years ago for a homegrown Linux solution and recently returned. Lots of amazing progress has been made over the past few years. But I am absolutely flabbergasted and disheartened to see that this issue is still open.

The obvious solution (to me, at least) is to replace the DHCPv4 Server (ISC DHCP), DNS Resolver (Unbound), and the "DHCP leases parsing daemon" (whatever that is) with dnsmasq, which addresses all of these needs and resolves this issue. It also solves the issue of Unbound needing to restart with every DHCP lease. ISC DHCP was discontinued a year ago, so it makes sense to consider a replacement, and pfSense is already using dnsmasq for the DNS Forwarder. dnsmasq is feature-rich and actively maintained.

As a SWE I also understand that the gulf between "the obvious solution" and an actual implementation can be enormous. But I hope this is at least being considered. Cheers.

EDIT: I wrote up a guide¹ on how to use dnsmasq for DHCPv4 in pfSense.

1. https://gist.github.com/mwpastore/9b47ba0fd9d07b93dbf795c4ee33dead

I, for one, would hate to lose a true DNS resolver (Unbound) and have just a forwarder (dnsmasq) as my only choice for DNS resolution. In any case, the devs are actively working on replacing ISC DHCP with Kea DHCP, which should resolve all the issues you mention, once implemented. See https://redmine.pfsense.org/issues/6960

I'm a network engineer and I long ago gave up on trying to use the firewall for an authoritative DNS solution that does DDNS updates from DHCP. Despite how convenient it would be, it's just not worth the trouble for anything mission-critical. We run BIND separately on other machines and we run DHCP separately on other machines, and we can get everything that we need (well except properly functioning HA with DDNS but that's ISC/DHCP's fault). None of this is to say that pfSense isn't suitable for mission-critical applications. It is with what it was designed for, which is firewalling and routing. Those are rock-solid.

I'm looking forward to the pfSense Kea updates to see if DDNS is integrated in an HA-compatible way that will update DNS servers properly and work after a failover as well.