MacOS – Safari OCSP/CRL Checking Causing Connectivity Failure

The main thing that looks odd from the setup that you've mentioned above is the DNS server. It appears that the IP address your computer has allocated is being assigned as the DNS server? If you're not running DNS services on your computer, this won't work very well.

Try to remove the single DNS server (i.e., your computer's IP address) from the list of DNS servers, and see if the machine populates that list with other entries (that were potentially provided via DHCP). If there are no DNS servers listed in that dialog box after you remove the single entry, I'd suspect configuration problems on your network.

Alternately, it may help to manually configure that network interface to use Google's open DNS servers (8.8.8.8, 8.8.4.4) to see if they will respond correctly to DNS lookups.

You can use the Network Utility program at /Applications/Utilities to perform further network troubleshooting. For example, it should be possible to "ping" the DNS server, router (gateway) and some outside host from where you are. This lets you know that your machine can communicate with those devices. First, I'd recommend trying to use Network Utility to ping the DNS servers that are being provided via DHCP. Under the "Ping" tab, you can enter the IP address of each of those hosts, and click "Ping" to see if you get a response. If all of the DNS servers are responding to pings, see if you can ping the gateway (10.58.204.1). If you receive responses for pings to all of the 'internal' hosts, see if you can ping some outside host (gmail.com?) to see if your computer's network traffic is being routed to the Internet.

If all of the ping tests are passing, I'd recommend trying to perform DNS lookups on the servers that are showing up in the DNS table in Network System Preferences. You can use the Network Utility program to perform lookups, but it may be more helpful to diagnose the DNS servers individually using 'nslookup' through the Terminal program. Open Terminal from /Applications/Utilities. When the program opens, you'll see a command prompt. Type in the following queries, and observe whether or not you receive valid responses from all of the DNS servers provided:

nslookup gmail.com 172.16.2.5
nslookup gmail.com 172.18.82.11
nslookup gmail.com 4.2.2.2

Those servers should respond with some answer (and IP address for gmail.com) within milliseconds. If you're seeing the commands hang for excessively long periods, that particular DNS server may not be responding correctly.

It's odd that you're having intermittent issues when using Google's DNS servers...If you're on some larger private network (as it appears you are based on the private addresses being provided), it's possible that traffic is being filtered.

Lastly, the Awarenet profile that you're using is simply utilized for authentication to a wireless access point named "Awarenet" that uses 802.1x (WPA Enterprise) security to authenticate users (you're signing in as egoodwin). If you no longer use/join a Wi-Fi network named "Awarenet" (for work, or school?), the profile can likely be deleted.

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.