Description of problem:
When specifying a FQDN with the DHCP_HOSTNAME variable in ifcfg-xxx file or using nmcli (ipv4.dhcp-hostname), only the hostname part is sent as DHCP Option 12.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set DHCP_HOSTNAME="rhel73.example.com" in ifcfg-eth0
2. Capture DHCP traffic: "tcpdump -i eth0 port 67 -V -x"
3. Restart NetworkManager: "systemctl restart NetworkManager"
DHCP capture shows the following
Option: (12) Host Name
Host Name: rhel73
Option: (12) Host Name
Host Name: rhel73.example.com
BZ #1255507 enables to specify the FQDN using DHCP_FQDN, but this has not the same effect since this translates into Option 81 as shown below and not Option 12:
Option: (81) Client Fully Qualified Domain Name
0000 .... = Reserved flags: 0x00
.... 0... = Server DDNS: Some server updates
.... .1.. = Encoding: Binary encoding
.... ..0. = Server overrides: No override
.... ...1 = Server: Server
A-RR result: 0
PTR-RR result: 0
Client name: rhel73.example.com
RFC 2132 (https://tools.ietf.org/html/rfc2132#section-3.14) clearly states that "The name may or may not be qualified with the local domain name", so FQDN should be accepted.
What about setting ipv4.dhcp-fqdn instead?
ipv4.dhcp-fqdn and DHCP_HOSTNAME send the string using Option 81, not Option 12.
Seems like DHCP servers handle this differently.
(In reply to Renaud Métrich from comment #4)
> ipv4.dhcp-fqdn and DHCP_HOSTNAME send the string using Option 81, not Option
> Seems like DHCP servers handle this differently.
The domain part was removed from the DHCP hostname option back in 2011
to fix bug 694758. Recently, in bug 1255507 we added support for the
FQDN option to allow the full domain name to be sent. Even if this is
a different option, I think that DHCP servers accept (and can update
DDNS with) both. Did you try using the DHCP_FQDN variable with NM?
We could modify NM to send the full domain in the hostname option, but
that would be a big change in behavior with the potential of breaking
many users; so before we start to look into adding new configuration
options to NM, please confirm that setting the DHCP_FQDN variable does
> The default behaviour should not be changed, but if
> NetworkManager encounters a FQDN, it should send it as-is.
Yeah, if DHCP_HOSTNAME is not set, we should keep sending only the
host part of the system hostname, to maintain backwards compatibility.
Instead, when an explicit value is set probably we should send it as
is because the user knows better what to do. However this would be
change in behavior for those who have a DHCP_HOSTNAME=FQDN set in
Alternatively, we could introduce a prefix (for example '!') that,
when used before the hostname value, tells NM to use the full value
instead of truncating it.
I think the DHCP_HOSTNAME should be compatible when using NetworkManager or legacy networking (ifup), hence transmit string as is.
I don't think many users set FQDN as hostname and think only the hostname part will be sent.
Whether users were aware of that is not really important. Important is that on upgrade the behavior will change.
I think now we should fix behavior, because it seems to be just a bug. But clearly document it in the release-notes.
(In reply to Thomas Haller from comment #11)
> Whether users were aware of that is not really important. Important is that
> on upgrade the behavior will change.
> I think now we should fix behavior, because it seems to be just a bug. But
> clearly document it in the release-notes.
I tend to agree. How about branch bg/dhcp-full-hostname-rh1443437 ?
(In reply to Beniamino Galvani from comment #12)
> (In reply to Thomas Haller from comment #11)
> > Whether users were aware of that is not really important. Important is that
> > on upgrade the behavior will change.
> > I think now we should fix behavior, because it seems to be just a bug. But
> > clearly document it in the release-notes.
> I tend to agree. How about branch bg/dhcp-full-hostname-rh1443437 ?
Sure, explicit DHCP_HOSTNAME should be transmitted untouched.
Merged to master:
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.