Skip to main content

Hi Jamf Community,


We're experiencing an interesting DNS registration issue with our Mac fleet that I'm hoping someone might have encountered before.


Issue Description


When our Mac devices connect to our corporate WiFi network, they register in DNS (Infoblox) with generic names like mac.domain or macbook.domain instead of their proper hostnames (e.g., mbp-dav.domain). However, when these same devices connect via Ethernet cable, they register correctly with their actual hostnames.


Environment Details



  • DNS/DHCP: Infoblox

  • Mac devices: Various models running macOS

  • All Mac devices have proper hostnames configured


What I've Verified


I've confirmed the hostname settings are correctly configured on the affected devices:














System preferences show the hostname is correctly set in the Mac's configuration, and I've checked the DHCP packets which don't seem to include any hostname options that might cause this behavior.


 


Questions



  1. Has anyone else encountered this issue where Macs register differently on WiFi vs. wired connections?

  2. Are there specific settings in Jamf or on the Mac that could address this inconsistency?

  3. Could this be related to how the Mac's mDNS/Bonjour services interact with Infoblox on different network types?


Any insights or suggestions would be greatly appreciated. Thanks in advance for your help!

@__AMM Have you checked with Infoblox support? I think this is a known issue.

It sounds like your Macs are using a different method to register their hostname in DNS over Wi-Fi versus wired connections. Here are some potential causes and troubleshooting steps:


1.DHCP Hostname Registration: Some Wi-Fi networks don’t properly pass the client hostname to the DHCP server, leading to default generic names. Check if your Wi-Fi VLAN is configured to allow hostname registration.


2.mDNS vs. DNS Registration: macOS uses both mDNS (Bonjour) and traditional DNS. When on Wi-Fi, the system may prioritize mDNS, leading to unexpected hostname behavior. Ensure that SetHostName, SetComputerName, and SetLocalHostName are consistent across network interfaces.


3.Infoblox DHCP Settings: Since your Macs register correctly over Ethernet, the issue could be Infoblox treating Wi-Fi connections differently. Verify if Infoblox has separate handling for hostnames based on interface type and check if Dynamic DNS updates are enabled for wireless connections.


4.Jamf Configuration Profiles: If Jamf is enforcing a naming convention, make sure it applies to all interfaces, including Wi-Fi.


5. Try Manually Registering Hostname: Run:


sudo scutil --set HostName mbp-xyz.domain.com

sudo scutil --set LocalHostName mbp-xyz

sudo scutil --set ComputerName mbp-xyz

dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Then reconnect to Wi-Fi and see if it resolves the issue.


If the problem persists, checking Infoblox logs and DHCP lease details might provide more insights.

we opened a ticket with Infoblox, but they have indicated that the issue is not on their end.


I’ve also verified the local settings on the affected Macs, including the hostname configuration in all three places (HostName, LocalHostName, and ComputerName), and the issue persists.


Any additional thoughts or suggestions would be appreciated.

we opened a ticket with Infoblox, but they have indicated that the issue is not on their end.

I’ve also verified the local settings on the affected Macs, including the hostname configuration in all three places (HostName, LocalHostName, and ComputerName), and the issue persists.

Any additional thoughts or suggestions would be appreciated.

We’re seeing the same thing now. Getting “mac.*domain*” or “macbookpro.*domain*” on Sequoia devices (doesn’t appear to be an issue on older OSs)

​@__AMM  did you ever find out what was happening?

Doing some more testing, it appears the cause of this is the Private Wi-Fi Address feature. Setting this to Off allows proper DNS resolution. This appears to be a Sequoia issue. Tested this on the beta of Tahoe and this problem is no longer manifesting.

Reply


Terms & ConditionsCookie settings