ddns correct setting for dhcpd.conf and ifcfg file with regards to hostname

Question

I have recently set up dynamic dns with ISC dhcpd 4 and bind 9. Everything is working as it should except for a handful of hosts on the network which don't resolve. Upon investigating I found they had been dynamically added into the bind zone file but they had their domain name appended with the host name.

for example server1 is fine but server2 wont resolve:

$TTL 1800   ; 30 minutes
server1                 A   192.168.0.10
            TXT "00ecbb5990a60bb0b138272611cae0f56d"
server2.reh.favsys.net  A   192.168.0.11
            TXT "00ecbb5990a60bb0b138272611cae0f56d"

I checked out server2 to see what was different I found that in the /etc/sysconfig/netowrk-scripts/ifcfg-eth0 file the DHCP_HOSTNAME option was set with a fqdn: DHCP_HOSTNAME=server2.my.domain.net where as server1 had just the host name: DHCP_HOSTNAME=server1

Right so I guess I just have to find all the servers with this problem and change the interface file to just contain the host name.

That's fine and could be done but is this the right way to configure the interface file? should the the DHCP_HOSTNAME option be an unqualified name.

Or is there a setting I can turn on in the DHCP server's configuration file to stop this kind of behaviour from happening. If there was a way to configure dhcp to disregard the domain part if a client sent in its host name fully qualified I would much rather take this approach.

my current dhcpd.conf options are:

include "/etc/rndc.key";
ddns-update-style interim;
ddns-domainname         "my.domain.net.";
ddns-rev-domainname     "in-addr.arpa.";
ddns-updates            on;
ignore client-updates;
option domain-search "my.domain.net";
default-lease-time 1800;
max-lease-time 7200;
log-facility local7;
authoritative;

I also tried configuring the dhcp server with allow client-updates to see if it would make a difference. However this just led to a dynamic update entry in the zone file like this:

$ORIGIN my.domain.net.
$TTL 1800   ; 30 minutes
server1                 A   192.168.0.10
            TXT "009ddasdr32rfdsfksdfpdsadsad3343fcdsd"
$ORIGIN my.domain.net.my.domain.net.
server2             A   192.168.0.11
            TXT "dasdasdsadasdsddvc0b1382726dsdadasdsd"

A new origin was created with the domain name repeated and the host name was still not resolvable.

I would really appreciate any pointers on the correct way to configure host names on clients when using dhcp and bind for ddns thanks.

EDIT adding subnet scope Sorry for the scope omission here is an example of one of the subnets option domain-name is specified within the scope

 subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.10 192.168.0.250;
  next-server 192.168.0.2;
  filename "/pxelinux.0";
  option broadcast-address 192.168.0.255;
  option routers 192.168.0.1;
  option domain-name-servers 192.168.0.3;
  option domain-name "my.domain.net";

 }

Answer 1

The ddns-domainname and ddns-rev-domainname options are not necessary, since your style is interim (as it should be).

ignore client-updates is supposed to ignore whatever it is that the client thinks their FQDN should be. You're doing that correctly.

It is odd that you are not specifying option domain-name "example.net" where example.net is your domain name. This can be global or it can be scope-specific (you've omitted your scope for some reason; it might have been important).

However, I see that the problem is it thinks the DNS suffix of your second server is my.domain.net.my.domain.net.. It thinks this because, although it is correctly ignoring the server's assertion as to its DNS suffix (or domainname), server2 is telling the DHCP server that its hostname (to which the FQDN suffix would be added) is server2.my.domain.net. The hostname shouldn't have any .s in it. While it is odd and perhaps a misfeature that dhcpd does not strip this or reject it, server2 is misconfigured and that is the only place that you can correct this.

Before the interim method was established, for static leases, it was possible to use the ddns-hostname option to override the client's assertion. This is no longer usable.

Even now, for clients which accept their hostname from the DHCP server as specified in a static lease (most linux and several other things, but not windows), you can control this behaviour from the DHCP server. However, it doesn't sound like this describes your environment.