DNS Search Domains not working / being ignored

[v654321]

I'm facing an issue with DNS search domains not working and/or being ignored. I've been trying to troubleshooting/pinpoint the issue but unfortunately to no avail. I've googled fairly extensively and tried multiple options such as flushing the DNS cache, resetting my entire network setup, adding /etc/resolver/lan files etc, but nothing seems to work. I'm hoping one of you could point me in the right direction or speak out of experience on how she/he got this fixed. I am at a loss as the dhcp / dns configuration fully works out of the box on all of my other Linux/Windows machines, but my MBP is not liking the internal hostname resolution.

Problem statement: My MBP is getting an IP address assigned via DHCP, using a Pi-hole, with an unbound DNS resolver. I use an internal domain name "home.arpa" and that gets added as a DNS search domain, including the IP of my DNS server (192.168.1.4). Each device on my network has a hostname.

On my Linux and Windows machines i can perfectly ping the same device using both the FQDN (eg. ap12.home.arpa or kodi.home.arpa) and the hostname itself (eg. ap12 or kodi) as the search domain gets automatically added. However, on my MBP it simply does not work, as if the search domain is not even existing/being ignored. I can perfectly ping the FQDN but the hostname itself always fails. I have not provisioned my /private/etc/hosts file with these hostnames or FQDN as the DNS config should take care of that (and it does on my non-MacOS machines). I've tried even with fixed IP configuration (both static IP, DNS and DNS search domains) but no difference.

Apologies if this is not appreciated, but I've added some screenshots of both Windows, Linux and MacOS Big Sur with their config and ping results:

Windows 10:


Linux:



MacOS Big Sur:




From what my googling has revealed it seems the search domain is a problem that came up in the past for several users, but i didn't find any threads that made this a structural problem. It was most of the time linked to VPN's (split tunneling DNS) or missing/wrong search domains. It made me conclude that with a proper config, it was all considered to be working.

I silently hope some of you can guide/help me figure out what might be wrong or what i can do to alleviate this. Obviously i can hardcode the hostnames/FQDN's in the /private/etc/hosts file, but as I'm playing with alot of computers and VM's, i'd like to be able to rely on DNS resolution that is fully automated.

Thanks in advance for your potential interest/involvement!

 

[HenryAZ]

Problem statement: My MBP is getting an IP address assigned via DHCP, using a Pi-hole, with an unbound DNS resolver. I use an internal domain name "home.arpa" and that gets added as a DNS search domain, including the IP of my DNS server (192.168.1.4). Each device on my network has a hostname.

Do you have a local zone configured for home.arpa in unbound at 192.168.1.4 ?

 

[v654321]

Thank you HenryAZ for your involvement!

The home.arpa internal domain is configured in the pihole web interface. My original setup description might not have been complete. My apologies for this.

The configured DNS server on all my computers is the pihole IP address, who - if it does not have the requested domain in its cache , nor is it on the preconfigured blocklists - forwards it to the unbound service (running on localhost on the pihole) who will then reach out to the DNS root servers to identify the TLD DNS servers etc, until the necessary IP's for external domains are received. There's no local zone config needed on unbound since this is done on the pihole web interface. I used the following setup guide and followed it to the letter. Only the MBP fails for hostname only lookups, all other machines work perfectly.

Running the following command on Linux works perfectly (kodi gets extended automatically with the search domain so becomes kodi.home.arpa:
$ ping kodi PING kodi.home.arpa (192.168.1.35) 56(84) bytes of data. 64 bytes from kodi.home.arpa (192.168.1.35): icmp_seq=1 ttl=64 time=0.733 ms 64 bytes from kodi.home.arpa (192.168.1.35): icmp_seq=2 ttl=64 time=0.718 ms

This results in the following logs on pihole:
May 23 13:34:14 dnsmasq[10080]: query[A] kodi.home.arpa from 192.168.1.11 May 23 13:34:14 dnsmasq[10080]: /etc/pihole/custom.list kodi.home.arpa is 192.168.1.35 May 23 13:34:14 dnsmasq[10080]: query[PTR] 35.1.168.192.in-addr.arpa from 192.168.1.11 May 23 13:34:14 dnsmasq[10080]: /etc/pihole/custom.list 192.168.1.35 is kodi.home.arpa

However, doing the same from my MBP:
% ping kodi ping: cannot resolve kodi: Unknown host % ping kodi.home.arpa PING kodi.home.arpa (192.168.1.35): 56 data bytes 64 bytes from 192.168.1.35: icmp_seq=0 ttl=64 time=4.889 ms 64 bytes from 192.168.1.35: icmp_seq=1 ttl=64 time=5.530 ms

This results in the following logs on pihole:
May 23 13:35:26 dnsmasq[10080]: query[A] kodi from 192.168.1.78 May 23 13:35:26 dnsmasq[10080]: config kodi is NODATA-IPv4 May 23 13:35:30 dnsmasq[10080]: query[A] kodi.home.arpa from 192.168.1.78 May 23 13:35:30 dnsmasq[10080]: /etc/pihole/custom.list kodi.home.arpa is 192.168.1.35

This shows that on the MBP the first ping attempt fails because the search domain is not automatically added to become the FQDN (kodi.home.arpa) while the second request is correctly treated. Both requests do arrive at the pihole, but the search domain is not applied despite it being present in the IP configuration as provided by the DHCP.

Unless I'm missing something else, I'd dare to conclude that given both the Linux host and the MBP get their IP and DNS information identically from the same DHCP, that they contact the same DNS server (pihole) and that it works perfectly on my Linux host (not the pihole) but not on the MBP, the DNS Search Domain is not being applied to a host only ping command. I really have no idea what else i can change to make this work.

 

[HenryAZ]

Unless I'm missing something else, I'd dare to conclude that given both the Linux host and the MBP get their IP and DNS information identically from the same DHCP, that they contact the same DNS server (pihole) and that it works perfectly on my Linux host (not the pihole) but not on the MBP, the DNS Search Domain is not being applied to a host only ping command. I really have no idea what else i can change to make this work.

I would hazard to guess that macOS' implementation of NetBIOS is not as robust as the other two, which are able to resolve given the host name only. You do have NetBIOS enabled on your Mac? It is by default. I don't think the search path really matters, that Windows and Linux are doing NetBIOS name resolution of the host name to get its IP address, rather than DNS.

With unbound, you have the luxury of using it as a validating resolver, for outside zones, without have to forward requests. And as a resolver for a local zone.

 

[korwynkim]

I'm facing an issue with DNS search domains not working and/or being ignored. I've been trying to troubleshooting/pinpoint the issue but unfortunately to no avail. I've googled fairly extensively and tried multiple options such as flushing the DNS cache, resetting my entire network setup, adding /etc/resolver/lan files etc, but nothing seems to work. I'm hoping one of you could point me in the right direction or speak out of experience on how she/he got this fixed. I am at a loss as the dhcp / dns configuration fully works out of the box on all of my other Linux/Windows machines, but my MBP is not liking the internal hostname resolution.

Problem statement: My MBP is getting an IP address assigned via DHCP, using a Pi-hole, with an unbound DNS resolver. I use an internal domain name "home.arpa" and that gets added as a DNS search domain, including the IP of my DNS server (192.168.1.4). Each device on my network has a hostname.

On my Linux and Windows machines i can perfectly ping the same device using both the FQDN (eg. ap12.home.arpa or kodi.home.arpa) and the hostname itself (eg. ap12 or kodi) as the search domain gets automatically added. However, on my MBP it simply does not work, as if the search domain is not even existing/being ignored. I can perfectly ping the FQDN but the hostname itself always fails. I have not provisioned my /private/etc/hosts file with these hostnames or FQDN as the DNS config should take care of that (and it does on my non-MacOS machines). I've tried even with fixed IP configuration (both static IP, DNS and DNS search domains) but no difference.

Apologies if this is not appreciated, but I've added some screenshots of both Windows, Linux and MacOS Big Sur with their config and ping results:

Windows 10:
View attachment 1779705

Linux:

View attachment 1779706

MacOS Big Sur:

View attachment 1779712


From what my googling has revealed it seems the search domain is a problem that came up in the past for several users, but i didn't find any threads that made this a structural problem. It was most of the time linked to VPN's (split tunneling DNS) or missing/wrong search domains. It made me conclude that with a proper config, it was all considered to be working.

I silently hope some of you can guide/help me figure out what might be wrong or what i can do to alleviate this. Obviously i can hardcode the hostnames/FQDN's in the /private/etc/hosts file, but as I'm playing with alot of computers and VM's, i'd like to be able to rely on DNS resolution that is fully automated.

Thanks in advance for your potential interest/involvement!

Did you ever resolve this issue? Maybe with a newer version of MacOS?

 

[palebluedot]

I wonder if this has something to do with the annoying implementation of DNS-SD on Mac and Bonjour? Meaning it defaults to that instead of search domain?