First, are you sure the server B gets the wrong IP from DNS? It might have an local DNS cache, which might cause the deprecated information to linger.
Some versions of
nscd (name server cache daemon) might have the option to flush DNS caching in a per-user basis:
nscd -I hosts. If that does not work, you might need to run some command as root:
systemd-resolved.service is in use, the command would be
- if the system is using
unscd, and the above-mentioned per-user command did not work,
nscd -i hosts would flush its DNS caches system-wide.
- if the system had ISC BIND configured as a caching resolver,
rndc flush would be the command to flush the cache.
There might even be no DNS server at all: the hostname resolution might be relying on mDNS (multicast DNS) Zeroconf/Avahi/Bonjour functionality. On server B, you could try
ping server_a.local to explicitly request a mDNS-based IP address, if the mDNS hostname resolution library is enabled in
If you are sure the deprecated information actually comes from the DNS server (i.e. you have used
dig to explicitly query that DNS server and it has replied with the wrong IP address), the next question will be: how is the DNS registration supposed to be updated?
There are several options. The DHCP server might be configured to update both forward and reverse DNS records; or it might be configured to update only the reverse-DNS records, and let the client do its own forward records (like a Windows AD domain does things by default, using its domain membership credentials to make secure DNS update requests), or the DHCP server might allow the DHCP client to specify whether it wants DNS updates done for it or not, using DHCP options.
Or if the DNS server administrator has not coordinated with the DHCP server administrator, there might be no automatic DNS updates at all, and all DNS information is actually updated manually. Obviously this is not an ideal situation in a DHCP-enabled network, but may work surprisingly well if there are plenty of IP addresses available, as both the DHCP client and the server will attempt to keep any previously-allocated IP address in use on the same host if possible.
(Sometimes Internet Service Providers' DHCP servers intentionally break this feature, to discourage users from relying on the IP address staying the same unless an extra-cost service agreement specifying a static IP address is made.)
If the DNS information has previously been automatically updated according to match DHCP, the default assumption would be that this should still be working.
You might try checking the settings of your DHCP client to verify it's setting the necessary DHCP option to request that the DHCP server should perform the DNS updates, and then disabling and re-enabling the network interface at server A.
If your system is using NetworkManager, use
nmcli c show <connection name> to view all the settings of the connection you're using: in order to pass the hostname to the DHCP server, either
ipv4.dhcp-fqdn should be set (mutually exclusive) with the
ipv4.dhcp-send-hostname enabled, and the
ipv4.dhcp-hostname-flags should have either the default value of 0, or value 3 to explicitly set the NM_DHCP_HOSTNAME_FLAG_FQDN_SERV_UPDATE (0x1) and NM_DHCP_HOSTNAME_FLAG_FQDN_ENCODED (0x2) flags.
If you are not using NetworkManager, see the documentation of your DHCP client to find out how to set the DHCP hostname/fqdn/DNSupdate options using that specific DHCP client.