Bug 2033643

(In reply to Colin Walters from comment #0)
> See https://bugzilla.redhat.com/show_bug.cgi?id=2008521
> and https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/572
> 
> NM is currently injecting a badly truncated hostname in /etc/resolv.conf
> search domains.

bug 2008521 is about something thats not NM storing a wrongly truncated hostname in /proc/sys/kernel/hostname which leads to the truncated search domain. NM will not change this.

> If NM adopts the same logic for truncating hostnames as we are hackily doing
> in GCP internally, then it can ensure that the search domains it writes to
> /etc/resolv.conf are also valid based on that truncated name.

Not sure what you mean with this.

The upstream issue is about handling overlong DHCP hostnames, this is a feature that NM can implement.
User Story:


As a Linux Administrator, I would like to use overlong DHCP host names in my networking setups, so that I can use the hostnames in Google Cloud Platform.

Acceptance criteria:

Given a Linux system using NetworkManager to handle DHCP on an interface
When the hostname from option 12 is 64 characters or less
Then the hostname is set as-is as the system hostname
And the substring after the first "." of the specified hostname is used as a search domain

Given a Linux system using NetworkManager to handle DHCP on an interface
When the hostname from option 12 is longer than 64 characters
Then the hostname will be truncated to the part before the first "." or truncated to 64 characters, depending what is shorter
And the substring after the first "." of the specified hostname is used as a search domain

Given a Linux system using NetworkManager to handle DHCP on an interface
When the hostname from option 12 contains a "." as the first character
Then NM will reject the hostname and log an error.

Colin, please confirm these acceptance critera.

(In reply to Beniamino Galvani from comment https://bugzilla.redhat.com/show_bug.cgi?id=2008521#c32)
> I think we have to distinguish the two cases:
> 
>  1) when NM finds the truncated hostname already set;
> 
>  2) when NM sets the hostname from DHCP (or via reverse DNS) and
>     handles truncation.
> 
> Currently 1) happens in OCP because the MCO writes the truncated hostname.
> In this case, NM doesn't know whether the system hostname was truncated
> or not, so there is little to change there. What we could improve is
> that NM doesn't write search domains that are clearly invalid, like those
> ending with '-'.
 
It does not seem wise to try to partially fix a broken system. The code that sets the bad hostname should be fixed.

> 
> Anyway, I think we agree that the better solution is 2). In such case
> NM would be in control of the hostname and would truncate it according
> to these rules:
> 
>  - if the first MAX_LENGTH characters contain a dot, then the hostname
>    is truncated to the dot. The part after the first dot of the the
>    original hostname is used as search domain in resolv.conf.

It should only truncate if the hostname would be longer than MAX_LENGTH characters. jupiter.example.com does not need to be truncated.
> 
>  - otherwise, truncate to the first MAX_LENGTH characters. The part
>    after the first dot of the the original hostname is used as search
>    domain in resolv.conf.

Another option would be not to set the hostname it it needs to be truncated before a dot, since this appears to be a broken configuration.

> 
> MAX_LENGTH is 64. Does this sound ok?
> 
> According to [1] in some scenarios there is the need to enforce a hostname
> not longer than 63 characters. In that case, we can make MAX_LENGTH
> configurable with a global config option (e.g. main.hostname-max-length).
> Thoughts?

I prefer to first add support for 64 chars to keep it simple. Then check the next use case. If kubernetes needs 63 characters, then it seems like something that the admin can control already by properly configuring hostnames. Another option might be to always use 63 chars as a limit to avoid bloating the configuration options.

Another solution could be to always truncate the hostname at the first dot. What would be the downside of this? Since NM will still set the search list, what's the additional value of setting the full hostname?

(In reply to Till Maas from comment #4)
> Another solution could be to always truncate the hostname at the first dot.
> What would be the downside of this? Since NM will still set the search list,
> what's the additional value of setting the full hostname?

When configuring the hostname statically, both short and fqdn forms are supported and valid:

  https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/system_design_guide/graphical-installation_graphical-installation#network-hostname_configuring-system-settings

I assume that also when the hostname comes from DHCP, the network administrator should be able to choose whether to assign a short or a FQDN hostname to clients.

Created attachment 1864309 [details]
Reproducer script

Thanks Ana for spotting those issues. Regarding the first one:

> Work as expected:  Input (64 characters):   xxx-test-dhcp-this-one-here-is-a-long-domain-examplx.example.com
>                    Produced hostname:       xxx-test-dhcp-this-one-here-is-a-long-domain-examplx.example.com
>                    Produced search domain:  example.com

I think that the original acceptance criteria were not
correct. According to the DNS RFC [1], each label in a valid domain
name must be no longer than 63 characters. The RFC also says that the
total length must be <= 255, but Linux has always had a tighter
restriction at 64 characters [2].

[1] https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1
[2] https://man7.org/linux/man-pages/man2/gethostname.2.html#NOTES

Anyway, currently both DHCPv4 client implementations in NM (dhclient,
internal) ignore the hostname option when it has labels longer than
63. That seems the correct thing to do in my opinion.


Regarding:

> Input: .name.example.com                    Work: NM rejects the hostname.
>                                             Missing: The error log message.

invalid options are ignored by the DHCP clients. For dhclient, it's
not possible to log a message, since it's an external binary. With the
internal client, it would be possible, but it doesn't happen
currently. I guess the reason for that is that we don't want to add a
lot of logging code for each possible way in which an option can fail
to validate.


Therefore, I suggest to amend the acceptance criteria in the following
way:

  Given a Linux system using NetworkManager to handle DHCP on an interface
  When the hostname from option 12 is 64 characters or less (with each label of 63 characters or less)
  Then the hostname is set as-is as the system hostname
  And the substring after the first "." of the specified hostname is used as a search domain

  Given a Linux system using NetworkManager to handle DHCP on an interface
  When the hostname from option 12 is longer than 64 characters (with each label of 63 characters or less)
  Then the hostname will be truncated to the part before the first "."
  And the substring after the first "." of the specified hostname is used as a search domain

  Given a Linux system using NetworkManager to handle DHCP on an interface
  When the hostname from option 12 contains a label longer than 63 characters
  Then NM will ignore the hostname

  Given a Linux system using NetworkManager to handle DHCP on an interface
  When the hostname from option 12 contains a "." as the first character
  Then NM will reject the hostname

Any opinion?

Fernando is going to review the new acceptance criteria.

(In reply to Beniamino Galvani from comment #14)

> Therefore, I suggest to amend the acceptance criteria in the following
> way:

> Any opinion?

Is your proposal to replace the acceptance criteria from comment 2?
What is the reason to reject the hostname in one case but ignore it in the other? It seems to me that rejecting it (i.e. logging an error) would be beneficial over silently ignoring it. Also, why does it matter for the hostname whether any label is correct?

I discussed this with Beniamino today and we came to this conclusion:

Labels are the components of a FQDN separated by dots.


(In reply to Beniamino Galvani from comment #14)



>   Given a Linux system using NetworkManager to handle DHCP on an interface
>   When the hostname from option 12 is 64 characters or less (with each label
> of 63 characters or less)
>   Then the hostname is set as-is as the system hostname
>   And the substring after the first "." of the specified hostname is used as
> a search domain

Sounds good.


>   Given a Linux system using NetworkManager to handle DHCP on an interface
>   When the hostname from option 12 is longer than 64 characters (with each
> label of 63 characters or less)
>   Then the hostname will be truncated to the part before the first "."
>   And the substring after the first "." of the specified hostname is used as
> a search domain

Since the unqualified hostname is also a label (the part before the first "."), this implies that a truncated hostname will always be at most 63 characters.


>   Given a Linux system using NetworkManager to handle DHCP on an interface
>   When the hostname from option 12 contains a label longer than 63 characters
>   Then NM will ignore the hostname

Then NM will ignore the DHCP option 12 completely and not change the hostname or search domain based on this option and log an error that the DHCP option was ignored when using the internal DHCP client.

Note: dhclient silently ignores malformed DHCP options.

And additionally:
Given a Linux system using NetworkManager to handle DHCP using the internal DHCP client
When NM receives a DHCP option that it understands but cannot process due to it being malformed
then NM will log an error that this DHCP option was ignored.

>   Given a Linux system using NetworkManager to handle DHCP on an interface
>   When the hostname from option 12 contains a "." as the first character
>   Then NM will reject the hostname

ok.

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 (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7680