OES DHCP server not handing out IP addresses. Error: not authoritative

  • 7003523
  • 12-Jun-2009
  • 17-Jan-2013


Novell Open Enterprise Server 2 (OES 2) Linux
Novell Open Enterprise Server 11 (OES 11) Linux


Clients not getting IP addresses from the OES DHCP server.
Looking at the /var/log/messages file shows the DHCP server reporting that it is not authoritative to hand out addresses on the subnet.

In another case the clients may get an IP address but not get configured DHCP Options. See TID 7009129


Add the authoritative statement at the top of the /etc/dhcpd.conf file and restart the dhcp daemon.

The line to add is:

For a non-clustered (NCS) dhcp service, restart the daemon with:  rcnovell-dhcpd restart
For a clustered dhcp service, restart the daemon by off-lining and on-lining the clustered resource.
  For more information on a clustered dhcp service, please see TID 7011637.

Additional Information

From the man page for dhcpd.conf:

The authoritative statement


          not authoritative;

The DHCP server will normally assume that the configuration information about a given network segment is not known to be correct and is not  authoritative.   This is  so  that  if  a naive user installs a DHCP server not fully understanding how to configure it, it does not send spurious DHCPNAK messages to clients that have obtained addresses from a legitimate DHCP server on the network.

Network administrators setting up authoritative DHCP servers for their networks should always write authoritative; at the top of their configuration file to indicate  that  the DHCP server should send DHCPNAK messages to misconfigured clients.   If this is not done, clients will be unable to get a correct IP address after changing subnets until their old lease has expired, which could take quite a long time.

Usually, writing authoritative; at the top level of the file should be sufficient.   However, if a DHCP server is to be set up so that it is aware  of  some  networks for which it is authoritative and some networks for which it is not, it may be more appropriate to declare authority on a per-network-segment basis.

Note that the most specific scope for which the concept of authority makes any sense is the physical network segment - either a shared-network statement or a subnet statement that is not contained within a shared-network statement.  It is not meaningful to specify that the server is authoritative for some subnets within a shared network, but not authoritative for others, nor is it meaningful to specify that the server is authoritative for some host declarations and not others.