SMA1000: Troubleshoot MacOS & iOS Bonjour / Local DNS Conflict

Description

When using Mobile Connect on macOS or iOS to connect through a SonicWall SMA 1000 series VPN, users may be unable to resolve internal DNS names that end in ".local" (for example, server1.corp.local). This occurs because Apple operating systems reserve the .local top-level domain for Bonjour (mDNS) multicast DNS, which is used for peer-to-peer device discovery on the local network. Unicast DNS queries for .local names are intercepted by the Bonjour subsystem and never forwarded to the corporate DNS server over the VPN tunnel.

Root Cause

Apple macOS and iOS implement RFC 6762 (Multicast DNS), which reserves the .local domain for Bonjour service discovery. When the operating system encounters a DNS query for a hostname ending in .local, it routes the query to the mDNS resolver instead of the standard unicast DNS resolver. This behavior is by design and cannot be disabled globally. The VPN tunnel DNS server is never queried for .local names, causing resolution failures.

Resolution

Option 1: Migrate Away from .local

If you are planning a new network or can migrate your existing Active Directory domain, avoid using .local as your internal domain suffix. Use an ICANN-compliant domain suffix instead:

  • A subdomain of a domain you own (for example, corp.example.com) — this is the best practice per Microsoft and IETF guidance
  • .internal — recently reserved by IETF for private-use networks
  • .lan, .intranet, .private — commonly used but not formally reserved; functional for most environments

Option 2: Use Two-Label .local Names

If your network already uses .local, you can use two-label names (for example, "corp.local" instead of single-label "server.local"). Apple Bonjour treats two-label .local names differently and will forward them to the unicast DNS resolver in addition to mDNS. This is compliant with the IANA assignment of .local to Bonjour.

Option 3: MacOS Resolver Directory Workaround

On macOS, you can create a custom resolver configuration that forces .local queries to a specific DNS server. This workaround does not require changing the domain on the server side.

  1. Open Terminal on the macOS device.
  2. Create the resolver directory if it does not exist: sudo mkdir -p /etc/resolver
  3. Create a file named "local" in that directory: sudo nano /etc/resolver/local
  4. Add the following content (replace with your internal DNS server IP):
    nameserver 10.0.0.1
    timeout 2
  5. Save the file and test with: dscacheutil -q host -a name server1.corp.local

Important: The /etc/resolver/ workaround persists across reboots but must be configured on each macOS device. For managed environments, consider deploying this configuration via an MDM profile. This workaround is not available on iOS or iPadOS — for those devices, Option 1 or Option 2 is required.

SMA1000 DNS Configuration Check

Regardless of which workaround you use, verify that the SMA1000 tunnel DNS settings are correctly configured:

  1. In the AMC, navigate to System Configuration > DNS.
  2. Confirm that the DNS server listed can resolve your internal .local hostnames.
  3. Under the tunnel profile (Services > Settings), confirm the DNS search domain includes your internal domain suffix.
  4. If using split DNS, ensure that .local (or your replacement suffix) is included in the split DNS domain list.

Related Articles

  • SMA1000: Management Audit Logs Not Visible on Remote Syslog Server
    Read More
  • SMA1000: Why are Java Bookmarks no Longer Working?
    Read More
  • SMA1000: SNMP MIB Download and OID Location
    Read More
not finding your answers?