Project

General

Profile

Actions

Bug #1819

closed

DNS Resolver Not Registering DHCP Server Specified Domain Name

Added by NOYB NOYB over 13 years ago. Updated 2 months ago.

Status:
Duplicate
Priority:
Normal
Assignee:
Category:
DNS Resolver
Target version:
-
Start date:
08/29/2011
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:

Description

DHCP Server specified Domain Name not being registered in DNS Forwarder.

Hosts are resolvable by System General specified domain name instead.

Is this expected mode of opperation? Seem like they should be registered with the domain name they are being assigned.

2.0-RC3 (i386)
built on Sun Aug 28 15:02:45 EDT 2011


Files

System.DNSForwarderDHCPDomainName.FIX.patch (1.86 KB) System.DNSForwarderDHCPDomainName.FIX.patch patch -p0 -i System.DNSForwarderDHCPDomainName.FIX.patch NOYB NOYB, 08/29/2011 10:27 PM

Related issues

Related to Feature #15651: Kea DNS Resolver (Unbound) Integration (IPv4 and IPv6)ResolvedChristian McDonald

Actions
Actions #1

Updated by Ermal Luçi over 13 years ago

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

Actions #2

Updated by Chris Buechler over 13 years ago

  • Category set to DNS Forwarder
  • Target version deleted (2.0)
  • Affected Version changed from 2.0 to All

That's always worked that way, the domain filled in for the DHCP server if different from the primary domain name of the system is not used when registering hostnames. 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.

Actions #3

Updated by NOYB NOYB over 13 years ago

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...

Actions #4

Updated by NOYB NOYB over 13 years ago

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");
Actions #5

Updated by NOYB NOYB over 13 years ago

Attached patch should result in the following behavior for registering DHCP hosts in DNS Forwarder.

Statically Assigned Hosts:
Services DHCP per Interface Domain Name Field
  • Specified: Hosts should be registered in DNS Forwarder with Services DHCP per Interface specified Domain Name.
  • Not Specified: Hosts should be registered in DNS Forwarder with System General specified Domain Name.
Dynamically Assigned Hosts:
Services DHCP LAN Interface Domain Name Field
  • Specified: Hosts should be registered in DNS Forwarder with Services DHCP LAN Interface specified Domain Name.
  • Not Specified: Hosts should be registered in DNS Forwarder with System General specified Domain Name.

2.0-RC3 (i386)
built on Mon Aug 29 11:53:27 EDT 2011

Actions #6

Updated by Chris Buechler over 13 years ago

  • Target version set to 2.1

thanks. Too close to release to fix something that hasn't ever worked (probability of unintended consequences is always higher than you think), but will get it merged to mainline for 2.1.

Actions #7

Updated by NOYB NOYB over 13 years ago

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.

Actions #8

Updated by Chris Buechler over 12 years ago

  • Target version deleted (2.1)
Actions #9

Updated by Chris Buechler about 9 years ago

  • Status changed from New to Confirmed
Actions #10

Updated by Jacob Smith about 8 years ago

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.

Actions #11

Updated by → luckman212 about 8 years ago

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 :/

Actions #12

Updated by Luiz Souza about 8 years ago

  • Assignee set to Luiz Souza
Actions #13

Updated by Lynn Dixon over 7 years ago

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

Actions #14

Updated by xander bron over 7 years ago

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?

Actions #15

Updated by Hannes van Vuuren over 7 years ago

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.

Actions #16

Updated by xander bron over 7 years ago

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.

Actions #17

Updated by Jim Thompson over 7 years ago

  • Target version set to 2.4.1
Actions #18

Updated by Jim Pingle about 7 years ago

  • Target version changed from 2.4.1 to 2.4.2
Actions #19

Updated by Jim Pingle about 7 years ago

  • Target version changed from 2.4.2 to 2.4.3
Actions #20

Updated by Luiz Souza almost 7 years ago

  • Target version changed from 2.4.3 to 2.4.4
Actions #21

Updated by Oded Brilon almost 7 years ago

is there an ETA on this one?

Actions #22

Updated by Lynn Dixon almost 7 years ago

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.

Actions #23

Updated by Lynn Dixon almost 7 years ago

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

Actions #24

Updated by Luiz Souza over 6 years ago

  • Target version changed from 2.4.4 to 48
Actions #25

Updated by Jim Pingle almost 6 years ago

  • Target version changed from 48 to 2.5.0
Actions #26

Updated by S. Debreuil over 5 years ago

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.

Actions #27

Updated by Lynn Dixon over 5 years ago

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

Actions #28

Updated by Oded Brilon over 5 years ago

Lynn Dixon wrote:

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

+1

Actions #29

Updated by Jim Pingle over 5 years ago

  • Category changed from DNS Forwarder to DNS Resolver
Actions #30

Updated by Jim Pingle over 5 years ago

  • Subject changed from DNS Forwarder Not Registering DHCP Server Specified Domain Name to DNS Resolver Not Registering DHCP Server Specified Domain Name
Actions #31

Updated by xander bron over 5 years ago

Lynn Dixon wrote:

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

+1

Actions #32

Updated by Lynn Dixon about 5 years ago

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

Actions #33

Updated by Gabriele Gino almost 5 years ago

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

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

Actions #34

Updated by xander bron almost 5 years ago

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

Actions #35

Updated by Jim Pingle almost 5 years ago

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.

Actions #36

Updated by Anonymous about 4 years ago

  • Status changed from Confirmed to New
  • Target version changed from 2.5.0 to CE-Next
Actions #37

Updated by xander bron about 4 years ago

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.

Actions #38

Updated by Marcos M about 4 years ago

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.

Actions #39

Updated by Ondrej Sala over 2 years ago

bump
11 years later and still no fix?

Actions #40

Updated by Allistah F over 2 years ago

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?

Actions #41

Updated by Allistah F over 2 years ago

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?

Actions #42

Updated by xander bron over 2 years ago

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.

Actions #43

Updated by Mike Pastore about 1 year ago

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 guide1 on how to use dnsmasq for DHCPv4 in pfSense.

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

Actions #44

Updated by Glenn Hall about 1 year ago

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

Actions #45

Updated by Yousif Hassan 10 months ago

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.

Actions #46

Updated by Jim Pingle 2 months ago

  • Status changed from New to Duplicate
  • Target version deleted (CE-Next)

This is implemented as a part of #15651 -- Kea DHCP DNS Registration respects the domain name on DHCP settings as well as on individual static mappings.

Actions #47

Updated by Jim Pingle 2 months ago

  • Related to Feature #15651: Kea DNS Resolver (Unbound) Integration (IPv4 and IPv6) added
Actions

Also available in: Atom PDF