Internet Sharing handing out wrong DNS server address

I'm using a MacBook Pro with OS X Mavericks 10.9.2. It connects to the internet via a USB 3G dongle, and I want to share that internet connection via wifi. However, on devices that connect to the created wifi access point, DNS lookup will not work (though I can ping 8.8.8.8 just fine). If I statically configure the devices to use 8.8.8.8, everything works, but not every device supports that (or only if you're also willing to configure a static IP and gateway).

The problem seems to be that OS X configures bootp (the DHCP server) to hand out a DNS server address of the MacBook itself:

$ cat /etc/bootp.list
...
            <key>dhcp_domain_name_server</key>
            <array>
                <string>192.168.2.1</string>
            </array>
...

This is indeed the IP address of the machine itself:

$ ifconfig
...
bridge100: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=3<RXCSUM,TXCSUM>
    ether 02:26:bb:66:19:64
    inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
...

And it's what clients are receiving in the DHCP response:

$ sudo tcpdump -vv
15:26:07.265635 IP (tos 0x0, ttl 255, id 9846, offset 0, flags [none], proto UDP (17), length 328)
    192.168.2.1.bootps > 192.168.2.2.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x4e0988af, Flags [none] (0x0000)
      Your-IP 192.168.2.2
      Server-IP 192.168.2.1
      Client-Ethernet-Address 10:bf:48:cc:49:7d (oui Unknown)
      sname "ip-77-24-232-37.web.vodafone.de"
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 192.168.2.1
        Lease-Time Option 51, length 4: 85536
        Subnet-Mask Option 1, length 4: 255.255.255.0
        Default-Gateway Option 3, length 4: 192.168.2.1
        Domain-Name-Server Option 6, length 4: 192.168.2.1

Now, that would be fine if it actually worked as written here, i.e. OS X runs a bind (named) server itself, that just forwards DNS requests and responses to the ISP's servers.

However... using tcpdump I can see that the client is getting an error response from its DNS lookups:

$ sudo tcpdump
15:23:33.181447 IP 192.168.2.2.57291 > 192.168.2.1.domain: 32713+ A? google.com. (28)
15:23:33.181528 IP 192.168.2.1 > 192.168.2.2: ICMP 192.168.2.1 udp port domain unreachable, length 36

Indeed, no named server is running, and it doesn't even seem to be installed:

$ ps aux | grep named
thomas           2175   0.0  0.0  2423368    188 s000  R+    3:14pm   0:00.00 grep named
$ which named
$

Nothing else is listening on UDP port 53 either, though there is a thing called mDNSResponder on 5353:

$ sudo lsof -i -P | grep 53
mDNSRespo   47 _mdnsresponder    8u  IPv4 0x4dcb7c0f075daa1d      0t0    UDP *:5353
mDNSRespo   47 _mdnsresponder    9u  IPv6 0x4dcb7c0f075da835      0t0    UDP *:5353
natpmpd   1664           root    4u  IPv4 0x4dcb7c0f064b6f15      0t0    UDP 192.168.2.1:5351

Now I can think of two ways to fix this, neither very practical:

1. Run some DNS server on UDP port 53. Unfortunately, none is installed.
2. Tell DHCP to hand out a DNS server address that actually works, like 8.8.8.8. Unfortunately, the InternetSharing application overwrites /etc/bootp.plist each time internet sharing is turned on, so even if I added an IP address there and even if it would work, it wouldn't work forever.

But something tells me that this should (and usually does) work correctly out of the box... what am I missing?

The article you reference was indeed correct for when it was published and that's how it works prior to Mavericks. Under Mountain Lion 'named' get's launched when Internet Sharing is active with /etc/com.apple.named.proxy.conf as the config file. This is all observable under Mountain Lion - I verified it.

However, domain name resolution isn't just based on DNS under OS X like it is in other OSen, but instead it's based on Directory Services -- which permits DNS lookups from flat-files, NIS, NetInfo, LDAP, ZeroConfig/Bonjour ... and DNS -- and it's mDNSResponder that's used for resolution of these name turns. (As per its man page mDNSResponder is also the system-wide Unicast DNS Resolver. It's what is (or should) doing the DNS resolution for your Internet Shared clients under Mavericks. (It was odd that they fired up named under Mt Lion rather than using mDNSResponder back then.)

When Internet Sharing is activated either named (pre-Mavericks) or mDNSResponder (Mavericks) is the "DNS server" that should perform name resolution for Internet Sharing, and that correctly makes 192.168.2.1 the DNS server for the NAPT'ed clients of Internet Sharing. So the straight and simple answer to your questions is that it's not handing out the "wrong DNS server address".

This demonstrable worked for me setting up Internet Sharing to share out my WiFi connection via Ethernet. Clients served by Internet Sharing sent DNS requests to 192.168.2.1 were observed to receive there queries correctly from a browser and when issuing dig @192.168.2.1 apple.com; I observed this in action with tcpdump to verify. Everything "just works" as you'd expect.

I note that in this configuration from the hosting Mac I'm also able to telnet 192.168.2.1 53 and connect to mDNSResponder. I also note that I have the Service Order for the configured networks set with WiFi having precedence over the Ethernet.

However when running this in reverse, sharing the Ethernet connection via WiFi I initially experienced the same issue you were seeing. Namely I saw the UDP DNS request sent over but no response back, just like you observed. Ping passed through to 8.8.8.8 and resolving against 8.8.8.8 using dig worked fine too. I was all prepared to write this up as a bug but I later had the opportunity to restart my MacBook Pro and tried this again, also assuring this time I had Ethernet having precedence over WiFi in the Network preference pane Service Order. This time it "just worked" and I wasn't able to recreate the issue. Problem solved by reboot and checking service order.

Additionally I verified that I could:

• Issue a dig @192.168.2.1 apple.com from a client (assigned 192.168.2.3) of Internet Sharing and receive a successful response. I also observed the UDP query and response using tcpdump:

01:01:05.620240 IP 192.168.2.3.58817 > 192.168.2.1.domain: 34923+ A? apple.com. (27) 01:01:06.051566 IP 192.168.2.1.domain > 192.168.2.3.58817: 34923 3/0/0 A 17.149.160.49, A 17.172.224.47, A 17.178.96.59 (75)

• From the hosting Mac was able to telnet 192.168.2.1 53 and receive a connection.

Internet Sharing has always been a bit fragile. I've often seen weird behavior and have found it's best to restart before attempting to run Internet Sharing or at least to "Make [the] Service Inactive" in Network Preferences for the interfaces in question and then set them active again. (Be sure also to "Apply" when making such changes".) Additionally the Service Order (which controls the default gateways) can also have an impact (as would be expected.) You may also wish to make sure you're using the Apple supplied Location "Automatic" (or a reasonable facsimile). Remember when debuging also that each network interface can have it's own gateway and prefered DNS server to use since after around Leopard or so.

So I'd suggest three things: (1) a reboot and confirm your network service order precedence and/or (2) a clean install of Mavericks to see if this resolves your issues, as well as (3) verify you can get Internet Sharing working where Ethernet is shared out over WiFi and vise versa. If you can't make (3) work then you need to look at something specifically configured wrong on your Mac and again that suggests a clean install.

If you can get it working for Ethernet -> WiFi and WiFi -> Ethernet, this suggests something with the USB Dongle -- and perhaps adjusting the Service Order so it's a higher precedence may be required.

Make sure also you don't have any Firewall rules or are running Little Snitch or anything that may interfere.

Internet Sharing appears also to have some debugging options if you issue

$ /usr/libexec/InternetSharing --help

These, and it's log file, along with the log file for mDNSResponder, might also be useful if you're still having issues.

But as the answer to the question: It's not handing out the wrong DNS server address in DHCP as 192.168.2.1 is the "right" DNS server for Internet Sharing to be handing out based on how it's designed to operate. And mDNSResponder is what should be handling DNS on the host running Internet Sharing under Mavericks. No `named is needed.

The problem seems to be in the place you've narrowed your search; although it's not a case of the clients getting handed the wrong DNS Server address, but more related to the clients not being able to use 192.168.2.1 as their DNS Server. It's unclear how you've got the DNS Servers setup on the system doing Internet Sharing, but the issue is likely within that realm. So with that, the dchp_domain_name_server IP address in bootpd.plist is correct (at least normally).

I would recommend doing some simple checks:

Open System Preferences > Sharing, then check the following:

1. Share your connection from: Wi-Fi
2. To computers using: Wi-Fi, Ethernet

If you check Ethernet on you may get a dialog:

If you turn on this port, your Internet Service provider might terminate your service to prevent you from disrupting its network.

In some cases (if you use a cable modem, for example) you might unintentionally affect the network settings of your ISP and violate the terms of your service agreement.

I'm not exactly sure what that means (although I feel violated by my ISP).

System Preferences > Network Settings > Ethernet/Wi-Fi:

1. Configure IPv4 - Using DHCP
2. Then under Advanced...
3. Configure IPv6 - Automatically

DNS Tab > DNS Servers:

(Normally this would be set to your Router IP from the previous TCP/IP Tab:
Router: ... (3G USB Dongle IP Address)

/etc/bootpd.list

1. Stop Internet Sharing.
2. Open /tmp/bootpd.plist
3. Locate this key:

<key>reply_threshold_seconds</key> <integer>4</integer>

1. Change the value 4 to 0
2. Start Internet Sharing.

*As you know when Internet Sharing is stopped it wipes out settings. One possible solution to that would be creating a cron job or launchagent that would always keep your settings. There's also quite a few options for bootpd that can be run via Terminal that you might not be aware.

Other notes:

• Check the device/computer(s) at 192.168.2.2, etc. are not blocking 192.168.2.1
• It's possible if the OS X internal firewall is enabled, OS X forwards and receives requests from the Internet to devices/computers using Internet Sharing, but might not forward the replies to them (DNS).
• Configure devices/computers to use a static IP, and DNS server(s) other than 192.168.2.1 (but may not be an optimal solution as you've said). Also, in certain circumstances setting static IP's may not work (DHCP is generally recommended for Internet Sharing and default).
• Some 3G USB Dongles/Routers have a setting AP Isolation, which should be disabled for Internet Sharing.

I know you're not a n00b and have likely already checked many of these things, however, it could just be one minor thing that you may have missed along the way perhaps. Additionally if none of these simple things seem to make a dent in solving the problem there are more specific commands I could provide pending the outcome.