System hostname not sent by DHCP

What is the problem

My computers hostname is not registered at the dhcp server. As a result it is not possible to access (ssh/sftp/etc.) or ping the computer using the hostname:

$ ping hostname.domain
ping: unknown host hostname.domain

Also we cannot succesfully perform a nslookup (or reverse lookup):

$ nslookup hostname.domain
Server:         <ip address>
Address:        <ip address>#53

** server can't find hostname.domain: NXDOMAIN
$ nslookup hostname
;; Got SERVFAIL reply from <ip address>, trying next server
Server:         <ip address>
Address:        <ip address>#53

** server can't find hostname: SERVFAIL

For me this was an issue as my automated backup-script relies upon finding my laptop using the hostname.

Note that this issue (seems to) appear only when using NetworkManager.

The bug

See the bug report.

NetworkManager has a setting “ipv4.dhcp-send-hostname” which controls this behaviour. This settings is default enabled (which is good). However, NetworkManager also needs to know the actual hostname, and there things go wrong. It does not correctly find the hostname of the computer. The hostname should be set in the setting: “ipv4.dhcp-hostname”.

Check if this bug is biting you

Use the nmcli tool to find the connection which needs to be modified:

$ nmcli connection 
NAME                UUID            TYPE             DEVICE
home.hanckmann.net  8e059174-<...>  vpn              --
WNP-RP-002          1b78bbb1-<...>  802-11-wireless  --
ethernet            77587c51-<...>  802-3-ethernet   enp0s25
.. etc ...

In my case I need to fix the ethernet connection.

Check the current values:

$ nmcli connection edit <connection uuid>
===| nmcli interactive connection editor |===

Editing existing '802-3-ethernet' connection: '77587c51-<...>'

Type 'help' or '?' for available commands.
Type 'describe [<setting>.<prop>]' for detailed property description.

You may edit the following settings: connection, 802-3-ethernet (ethernet), 802-1x, ipv4, ipv6, dcb
nmcli>

nmcli> print
===========================================================================
                 Connection profile details (ethernet)
===========================================================================
connection.id:                          ethernet
connection.uuid:                        77587c51-<...>
connection.interface-name:              --
connection.type:                        802-3-ethernet
connection.autoconnect:                 yes
.. etc ...

In this list look for “ipv4.dhcp-send-hostname” and “ipv4.dhcp-hostname”. If all is as I expect than it will tell you the following:

.. etc ...
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     --
.. etc ...

If indeed the “ipv4.dhcp-send-hostname” is empty or is filled with “–”, or “ipv4.dhcp-send-hostname” is set to no, than you are bitten by this bug (so read on).

How to solve it

If the “ipv4.dhcp-send-hostname” is not set to yes, then change the setting:

nmcli> set ipv4.dhcp-send-hostname yes

If indeed the “ipv4.dhcp-send-hostname” is empty or is filled with “–”, than fill it with the computers’ hostname:

nmcli> set ipv4.dhcp-hostname hostname

After this we should check if the changes where set correctly:

nmcli> print
===========================================================================
                 Connection profile details (ethernet)
===========================================================================
connection.id:                          ethernet
.. etc ...
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     hostname
.. etc ...

If this is correct, than the settings will be activated after reconnecting to the network.

Check if the changes worked

Check if it worked in a similar fashion as you check if the problem was there (see above).

$ nslookup hostname.domain
Server:         <ip address>
Address:        <ip address>#53

Name:   hostname.domain
Address: <ip address>

If you see something similar to this… all is/should be well.

Additional note

This text solves the issue for ipv4. I am unsure if the same problem exists for ipv6, however it seems to. If you replace ipv4 with ipv6 in this tutorial you will fix it there as well.

~~ Patrick