Project

General

Profile

Bug #1819

DNS Forwarder Not Registering DHCP Server Specified Domain Name

Added by NOYB NOYB about 6 years ago. Updated 7 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
DNS Forwarder
Target version:
Start date:
08/29/2011
Due date:
% Done:

0%

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

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

History

#1 Updated by Ermal Lu├ži about 6 years ago

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

#2 Updated by Chris Buechler about 6 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.

#3 Updated by NOYB NOYB about 6 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...

#4 Updated by NOYB NOYB about 6 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");

#5 Updated by NOYB NOYB about 6 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

#6 Updated by Chris Buechler about 6 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.

#7 Updated by NOYB NOYB about 6 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.

#8 Updated by Chris Buechler over 5 years ago

  • Target version deleted (2.1)

#9 Updated by Chris Buechler about 2 years ago

  • Status changed from New to Confirmed

#10 Updated by Jacob Smith 12 months 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.

#11 Updated by Luke Hamburg 10 months 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 :/

#12 Updated by Luiz Souza 10 months ago

  • Assignee set to Luiz Souza

#13 Updated by Lynn Dixon 7 months ago

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

#14 Updated by xander bron 7 months 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?

#15 Updated by Hannes van Vuuren 7 months 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.

#16 Updated by xander bron 7 months 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.

#17 Updated by Jim Thompson 6 months ago

  • Target version set to 2.4.1

#18 Updated by Jim Pingle 7 days ago

  • Target version changed from 2.4.1 to 2.4.2

Also available in: Atom PDF