It seems intended behaviour is not well specified anywhere in manual page. lease_set_hostname function in lease.c iterates over previous leases, calling kill_name(lease_tmp) on previous name instance with the same name. Excluding cases when hostname was set from configuration, which was unset according to example. One of hosts set address and IP pair, but hostname were dynamically set.

There seems to be mismatch of checking runtime, which allows both machines with the same name to exist. But when loaded, different checks are done on leases, last loaded one cancels previous name in case of conflict. No clear indication what exactly the behaviour should be. But clearly it should not make difference between runtime name management and startup loading management, results should be the same.

Note: libvirt gui manager does not allow two instances named the same name.

This issue is still present even on the latest release 2.85 in Fedora. Tested it with Fedora 34 Live CD image, which sets hostname to "localhost-live". It allows both instances to have the same name when running. But after restart of libvirtd, only one record in virbr0.status file has "hostname": "localhost-live". After restart of those VMs, it will again have both hostnames set in status.


  {
    "ip-address": "192.168.122.102",
    "mac-address": "52:54:00:c4:a7:af",
    "hostname": "localhost-live",
    "client-id": "01:52:54:00:c4:a7:af",
    "expiry-time": 1625150434
  },
  {
    "ip-address": "192.168.122.151",
    "mac-address": "52:54:00:04:17:7d",
    "hostname": "localhost-live",
    "client-id": "01:52:54:00:04:17:7d",
    "expiry-time": 1625150441
  }

But at the same time, runtime status is different, it already replaced name with latest client.

$ dig @vhost.vm localhost-live.

; <<>> DiG 9.16.18-RH <<>> @vhost.vm localhost-live.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17470
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;localhost-live.			IN	A

;; ANSWER SECTION:
localhost-live.		0	IN	A	192.168.122.151

$ dig @vhost.vm -x 192.168.122.151

; <<>> DiG 9.16.18-RH <<>> @vhost.vm -x 192.168.122.151
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24930
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;151.122.168.192.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
151.122.168.192.in-addr.arpa. 0	IN	PTR	localhost-live.vm.

$ dig @vhost.vm -x 192.168.122.102

; <<>> DiG 9.16.18-RH <<>> @vhost.vm -x 192.168.122.102
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

I consider it a proof two machines of the same name are not intentionally supported.

I consider it strange feature, because it allows stealing registered name of existing client, still connected and with active lease. Just by requesting the same hostname as them. If anyone is using that name to connect to correct host, it is quite easy to impersonate original host. The only thing to protect the name is to register also lease name in configuration.

Created attachment 1797071 [details]
dnsmasq lease update on hostname reset

This patch does not allow two hostnames to have the same name in leases. Instead it fixes dnsmasq to run lease script also for lease with removed hostname from leases. If a new machine requests the same name, the last one gets the name and previous name is reset. I therefore matches state in DNS, which behaved this way even before.

It makes behaviour always the same, before or after libvirtd.service. As soon as new machine with the name starts, it moves hostname from previous to new record. /var/lib/libvirt/dnsamsq/virbrX.status is updated right away to reflect real state of leases.

Posted on upstream mailing list:
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q3/015237.html

Merged upstream in commit http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0c95a5ff532bd7cd33bf6ece1a94e899070b8419

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.