MacOS – How to get MacOS to use the correct search domain from DHCP

dnsmacosNetwork

Last year, my router broadcasted search domain was "home.lan".
After I changed the ISP, I set new search domain as "lan".
However, MacOS appears to ignore it completely and still use the old search domain.
How can I solve this issue?

# When my Mac is not connected to WiFi
myusername@myhostname $ hostname -f
myhostname.local
# When my Mac is not connected to WiFi
myusername@myhostname $ hostname -f
myhostname.home.lan
# Checked Network preferences: Shows correct search domain
# Checked other settings vis scutil
# Note that DHCP server/router address must be different from DNS server address in my network
myusername@myhostname $ scutil --dns                  
DNS configuration

resolver #1
  search domain[0] : lan
  nameserver[0] : 192.168.1.101
  if_index : 4 (en0)
  flags    : Request A records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

resolver #2
  domain   : local
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300000

resolver #3
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300200

resolver #4
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300400

resolver #5
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300600

resolver #6
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300800

resolver #7
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 301000

DNS configuration (for scoped queries)

resolver #1
  search domain[0] : lan
  nameserver[0] : 192.168.1.101
  if_index : 4 (en0)
  flags    : Scoped, Request A records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)
# As you can see, the correct search domain is shown in the output above.
# Further using ifconfig
myusername@myhostname $ ipconfig getpacket en0
op = BOOTREPLY
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 0xb4e66b8
secs = 0
ciaddr = 0.0.0.0
yiaddr = 192.168.1.159
siaddr = 0.0.0.0
giaddr = 0.0.0.0
chaddr = <snipped>
sname = 
file = 
options:
Options count is 9
dhcp_message_type (uint8): ACK 0x5
server_identifier (ip): 192.168.1.1
lease_time (uint32): 0x15180
subnet_mask (ip): 255.255.255.0
router (ip_mult): {192.168.1.1}
domain_name_server (ip_mult): {192.168.1.101}
domain_name (string): lan
domain_search (dns_namelist): {lan, home, homelab}
end (none): 
# The set hostname does not even resolve
# The DNS server resolves the expected FQDN correctly
myusername@myhostname $ dig myhostname |grep -A1 'ANSWER SECTION' 
;; ANSWER SECTION:
myhostname. 2   IN  A   192.168.1.159
myusername@myhostname $ dig myhostname.lan |grep -A1 'ANSWER SECTION'
;; ANSWER SECTION:
myhostname.lan. 2   IN  A   192.168.1.159
myusername@myhostname $ dig myhostname.home.lan |grep -A1 'ANSWER SECTION'
<no response>

So where is this machine getting the ".home.lan" Domain suffix?

Best Answer

hostname [-s|-f] and (sudo) scutil [--set|--get] [HostName|LocalHostName|ComputerName] (name) set/get the respective names locally only.

hostname`s set operations are ephemeral only and vanish after a reboot.

With the listed options scutil writes to and reads from /Library/Preferences/SystemConfiguration/preferences.plist only.

With the listed options both tools don't query (or feed) DNS-servers.

You probably set the hostname of your Mac locally to myhostname.home.lan with scutil in the past. To set another name locally (corresponding to your DNS-server's db) and persistently simply enter:

sudo scutil  --set HostName myhostname.lan

Your DNS-server and your search domain work perfectly well (and as expected). The search domain is meant to create a FQDN from a relative name.

If you enter a relative name the system adds the name(s) listed in the search domain list and tries to resolve them.

This is the reason why e.g. ping google (=in your case e.g. ping google.lan - assuming you don't have a host with the name google in your network/DNS-db) will fail but ping myhostname (=in your case e.g. ping myhostname.lan) will succeed.

Related Question