Description of problem: when a dhcp lease changes, NetworkManager does some DNS lookups, and then decides to rename the host to another name that it found off the internet. Version-Release number of selected component (if applicable): systemd-250.8-1.fc36.x86_64 NetworkManager-1.38.4-1.fc36.x86_64 How reproducible: not tried, this happened on a production system Actual results: Keycloak server suddenly changed its hostname due to a DHCP lease expiration. Aug 20 20:01:03 keycloak NetworkManager[1050]: <info> [1661036463.2213] dhcp6 (eno1): state changed new lease Aug 20 20:01:03 keycloak NetworkManager[1050]: <info> [1661036463.2421] policy: set-hostname: set hostname to 'ntp1.tummy.com' (from address lookup) Aug 20 20:01:03 keycloak systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service... Aug 20 20:01:03 keycloak audit: BPF prog-id=135 op=LOAD Aug 20 20:01:03 keycloak audit: BPF prog-id=136 op=LOAD Aug 20 20:01:03 keycloak systemd[1]: Starting systemd-hostnamed.service - Hostname Service... Aug 20 20:01:03 keycloak systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service. Aug 20 20:01:03 keycloak audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher com> Aug 20 20:01:03 ntp1.tummy.com systemd[1]: Started systemd-hostnamed.service - Hostname Service. Aug 20 20:01:03 ntp1.tummy.com audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm=> Aug 20 20:01:03 ntp1.tummy.com systemd-resolved[918]: System hostname changed to 'ntp1.tummy.com'. Aug 20 20:01:03 ntp1.tummy.com systemd-hostnamed[6256]: Hostname set to <ntp1.tummy.com> (transient) Expected results: * never change hostname based off some random IP lookup off the internet. * even if this is expected code-wise, probably the standard policy should prevent that and it should be an opt-in. Additional info: * this seems like a security flaw, as it does rename hosts in RFC 1918 networks. * seems to be either a configuration bug (fedora standard config) * the lookup that reached the conclusion to rename my host (192.168.15.43) to ntp1.tummy.com is not obvious. Although the name does match the A query on the on the internet, it is probably not doing a PTR request on 168.192.in-addr.arpa, as that is a reserved zone. Not sure at all how it decided on this address. $ dig ntp1.tummy.com ;; QUESTION SECTION: ;ntp1.tummy.com. IN A ;; ANSWER SECTION: ntp1.tummy.com. 0 IN A 192.168.15.43 ntp1.tummy.com. 0 IN A 172.17.0.1 for sure none of the DNS servers in my network do a PTR resolution to this address: <<>> DiG 9.16.31-RH <<>> -x 192.168.15.43 @192.168.15.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;43.15.168.192.in-addr.arpa. IN PTR ;; Query time: 3 msec ;; SERVER: 192.168.15.1#53(192.168.15.1) ;; WHEN: Sun Aug 21 03:41:06 -03 2022 ;; MSG SIZE rcvd: 55
The hostname is determined in the following ways, in order of precedence: 1) the statically configured hostname 2) from the hostname DHCP option 3) reverse-DNS lookup of the first address I suspect that when the DHCP lease changes and no longer offers a hostname, then reverse DNS lookup is used and finds the unexpected hostname. If you set "level=TRACE" in the [logging] section of /etc/NetworkManager/NetworkManager.conf and restart NM, you will see how the hostname is determined. > this seems like a security flaw, as it does rename hosts in RFC 1918 networks How is it a security flaw? It is perfectly valid to set the hostname based on reverse DNS lookup of a private address. This feature is heavily used in some environments (like corporate networks and cloud environments). If the problem is indeed the reverse lookup, you can disable it with something like: nmcli connection modify $CONNECTION hostname.from-dns-lookup no In such case, it seems to me that the network is wrongly configured, as the DNS server is returning a unexpected name for a private address lookup.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.