Bug 2120039

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