Description of problem: When not using systemd-resolved NetworkManager would create a search directive in /etc/resolv.conf based on information received from a DHCP server (if used) and information from the FQDN of the host. With the hostname of f31.greshko.com one would see [egreshko@f31k etc]$ cat resolv.conf # Generated by NetworkManager search greshko.com nameserver 192.168.122.1 And then, [egreshko@f31k etc]$ sudo hostnamectl set-hostname f31k.yang.com [egreshko@f31k etc]$ cat resolv.conf # Generated by NetworkManager search greshko.com yang.com nameserver 192.168.122.1 This is useful since sometimes a DHCP server may not provide domain information. Also, I believe, if static addresses are used that information is not available in any event. While it is possible to edit the /etc/systemd/resolved.conf it would be better if the hostmanectl behavior would be the same when working with systemd-resolved Version-Release number of selected component (if applicable): systemd-246.1-1.fc33 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I'm not sure what you think the bug is. Is it that the domain part of the hostname configured with 'set-hostname' is not used as a search domain? (Please don't describe the solution, describe the issue.)
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > I'm not sure what you think the bug is. Is it that the domain part > of the hostname configured with 'set-hostname' is not used as a search > domain? > > (Please don't describe the solution, describe the issue.) Yes, the domain part configured with 'set-hostname' isn't used as a search domain when the system is configured to use systemd-resolved. If the system isn't configured to use systemd-resolved then 'set-hostname" results in the domain part being used as a search domain. It should be consistent.
Setting the search domain like that by default is IMO not good. It is only reasonable when the whole domain is under the same control, and otherwise it's a pretty bad idea. (E.g. if my server is called foobar.com.sk... you get the picture.) OTOH, I can see how this can be useful in certain circumstances. hostnamectl and/or systemd-resolved should probably allow doing this easily. Right now the search domain has to be configured in a completely different way. I'll retitle the bug as an RFE for further investigation.
OK. If it is considered/determined to be a bad idea then removing the ability of set-hostname to set a search domain when not using systemd-resolved would be OK, IMO. The result is the same, consistency.
Hmm, search domains are very speciific to DNS while a hostname alone is kinda generic. hence, it might make sense to have an option to set a search domain in resolvectl, but probably not so much in hostnamectl. That all said, in todays multi-homed world, I am not sure if search domains should really be configured system-wide. i.e. aren#t they inherently bound to specific interfaces being up or down? And we already have ways to configure search domains for that, both from networkd and from NetworkManager, and resolved honours that. Hence, I am lukewarm about the idea. I think it doesn't belong in hostnamectl, but if at all into resolvectl, but not even sure about that as mentioned.
(In reply to Lennart Poettering from comment #5) > Hmm, search domains are very speciific to DNS while a hostname alone is > kinda generic. hence, it might make sense to have an option to set a search > domain in resolvectl, but probably not so much in hostnamectl. I would agree. The question then may be, why was hostnamectl given this feature to begin with? > That all said, in todays multi-homed world, I am not sure if search domains > should really be configured system-wide. i.e. aren#t they inherently bound > to specific interfaces being up or down? And we already have ways to > configure search domains for that, both from networkd and from > NetworkManager, and resolved honours that. I don't think name resolution has anything to do with specific interfaces. If I make a query for foo I'd expect the search domain be apended to the query regardless of path/interface taken to reach the destination. As well as regardless if the path is available or not. And when multiple addresses are returned by the query I expect the system(s) to make routing decisions based on supplied metrics. An example being one of my systems with 2 default routes. One is a wired connection, the other wifi. The wired connection is always used since it has a lower metric than the wifi. Wifi would only be used when the wired connection is down. > Hence, I am lukewarm about the idea. I think it doesn't belong in > hostnamectl, but if at all into resolvectl, but not even sure about that as > mentioned. Then, as I mentioned in another comment, the current behavior of hostnamectl could be changed. And, yes, I'm not so sure giving resolvectl the ability is a good idea either. It would probably have to feedback that information to NetworkManager for it to update its configurations. Needless complexity.
It is probably NetworkManager who is responsible for updating the search domain setting. It seems to ask for and receive property change messages via dbus from org.freedesktop.hostname1, As a result it updates the resolv.conf files found in /run/NetworkManager.
> That all said, in todays multi-homed world, I am not sure if search domains should really be configured system-wide. i.e. aren#t they inherently bound to specific interfaces being up or down? Some search domains are bound to specific interfaces. For example, a VPN might reasonably add a search domain only when it is up. But here we are discussing a search domain tied to the hostname, which is always set. This search domain is not related to any interfaces. > it might make sense to have an option to set a search domain in resolvectl And what about a simpler boolean switch to include the domain part of current hostname in the search path? In /etc/systemd/resolv.conf: either SearchHostDomain=yes|no, or allow Domains=$hostdomainnname ?
*** Bug 1976858 has been marked as a duplicate of this bug. ***
PR implementing the SearchHostDomain=yes|no switch: https://github.com/systemd/systemd/pull/22868
@cglombek any updates here since https://github.com/systemd/systemd/pull/22868 is now closed?
I've filed https://github.com/systemd/systemd/issues/24103
@dtardon could you provide a link to the PR that closed this?
There is not PR. Just the open issue.