Hacker News Reader

In my experience, discoveryd is at best at about the quality of beta software. With some regularity on several different Macs on different networks, it completely loses the ability to resolve names. Kill it and let launchd restart it, and suddenly names resolve again.

Another Yosemite daemon addition, recentsd, had serious issues (for example: substantial memory leaks when interacting with Mail.app) until 10.10.2.

Apple has gotten very good at eliminating crashes. They're obviously using the reporting mechanism there to great effect. But at the same time, Console.app has never been noisier, and failures that don't result in crashes seem to linger far too long.

They've also become, it seems, far more dependent on an "orchestra" of daemon processes to perform tasks that in the past would have been implemented in passive frameworks used separately by each app. That adds complexity of coordination, and meanwhile a single failure can affect every "client" app on the system.

For you and others with similar issues, add this to your .bashrc:

    function restart-discoveryd() {
        sudo launchctl unload /System/Library/LaunchDaemons/com.apple.discoveryd.plist
        sudo launchctl load /System/Library/LaunchDaemons/com.apple.discoveryd.plist
    }

Then simply run `restart-discoveryd` when you can't seem to ping google.com. I always struggle to remember how to start/stop things with launchd, so this is my little shortcut.

Or just `killall discoveryd` and let it relaunch on its own.

Try just doing

  sudo discoveryutil udnsrestartquestions

instead. The one time I had DNS issues (only once!), I ran that command and all of my DNS issues immediately resolved themselves.

I am not sure I understand what this command does, even after reading the man page for discoveryutil. Does it just restart any queries that have not been resolved, or does it restart the process as does my command? If it's the former, how does it work to fix whatever issues discoveryd is having?

It almost certainly does not restart the process.

In my short time poking around, my belief is discoveryd gets wedged into a state where it thinks DNS queries aren't resolving, and so it doesn't try to resolve them. I'm not sure what exactly is going on there, either all the queries are blocked somehow on some long-lived query that has no response and no timeout, or discoveryd thinks the network is broken and is waiting for it to come back (those are just guesses). Either way, the command tells discoveryd to restart any outstanding "questions" (which presumably means queries). When I had the issue, that was sufficient to flush out whatever it was that was blocking everything, as my machine instantly started working properly again.

The counter argument to this is that the RFC is exceedingly new, and directly from Apple. Microsoft has been using .local in example (and recommending them for production) AD builds for a decade. I see what Apple is going for, and I don't mind the idea, but the practical results are frustrating and pointless.

No, Microsoft has not been recommending .local, as this document, circa Windows Server 2000, states:

> Identify your organization's DNS owner and determine what registered DNS names you have available on the network that will host Active Directory.

> If you do not have a registered domain name, you should register a name with an Internet DNS registration authority.

https://technet.microsoft.com/en-us/library/bb727085.aspx

>

Actually they've said different things about it:

http://en.wikipedia.org/wiki/.local#Microsoft_recommendation...

The approved standard RFC is new but the proposal RFC and the practice of using .local for mDNS, like the convention of using .local for AD, goes back more than a decade. I agree that the whole thing is silly and pointless but it's not clear who "barged in" on whom.

.local doesn't work in Windows either as of Windows 8.

> All of the bugs cited have to do with ".local" domains. You should never use .local domains as IANA has designated this domain as a special use domain for Multicast DNS as part of IP Zeroconf and Bonjour. http://tools.ietf.org/html/rfc6762

That may be the official standard, but .local is a very common, de facto standard. Products need to be compatible with reality.

Just glancing at the RFC, is my impression correct that in February 2013, with .local already widely used for private domains, someone published an RFC appropriating the name for something else? (Could they have used a different name?) They expect the world to change their internal domains in order to accommodate their new idea?

Is there a standard for private second-level domain names? I've never seen one.

I got offline resolution with dnsmasq to work with

    # /usr/local/etc/dnsmasq.conf
    address=/.foobar/127.0.0.1

and

    # /etc/resolver/foobar
    nameserver 127.0.0.1

Odd, that's what I use:

# cat /usr/local/etc/dnsmasq.conf address=/dev/127.0.0.1

# cat /etc/resolver/dev nameserver 127.0.0.1

Instead of your choice of foobar.

Doesn't work offline. Your conf looks like the standard dnsmasq conf anyway, so maybe there's one other flag or configuration that you figured out?

the difference I see is that you are missing a period before "dev" in your dnsmasq.conf

I don't know how to configure dnsmasq at all, so that may not be a problem.

I ran into the same problem with Yosemite when offline in a plane this weekend. I'm using the same setup as you except I have .dev instead of just dev.

I've searched high and low after reading your reply, trying for an hour to jog my memory of how I got that to work.

Well, I found it — quite a few entries in /etc/hosts, made at 02:30 AM, together with unflattering comments about the parents of those responsible for Yosemites new DNS subsystem...

So sorry for getting your hopes up! I have no idea how I could have misremembered all that so badly.

>DNS is not broken, it is working as intended - just differently from the past.

Yeah, but the rewrite is buggy as rewrites often are. If it worked as intended, I doubt so many people would have so many problems.

I haven't had or heard of anyone having DNS problems personally in 10.10 and I have quite a few clients using it.

"it is working as intended - just differently from the past"

This is blatantly wrong. Any device on my network (which uses .lan as a suffix) that sleeps (including Apple TVs) gets the dreaded "(2)" (or 3, 4, 7), before I started disabling "Wake for Network Access".

Yes, things are different. But don't pretend that we're just "doing/holding it wrong". There are things that are -very- broken.

Are you sure that intermittent failure to name-resolve can solely be attributed to the handling of .local domains? It seems that if that was the case, the failures would be more deterministic

Multicast DNS isn't very predictable.

I have no bad experiences with resolving regular domains on Yosemite, but others in this tread have suggested bouncing discoveryd can help.

My Yosemite fails frequently resolving common domain names (.com). Has that something to do with .local domains and how could I fix it?

This most likely has to do with your DNS server. Try to change it to another one (e.g. Google's 8.8.8.8 or OpenDNS's 208.67.222.222) and see if it gets better.

Had the same problem popping up just after upgrading to Yosemite. Decided to do a clean install a couple of months ago as I saw other machines on my network didn't have this problem. After the clean install things are working out as expected again.

Not what I really wanted (checked quite a bit around for a solution without finding any), but at least I don't have this happening multiple times a day.

That sounds like a good reason/background story for Apple to change the existing mDNSresponder, but how are the issues in the article not signs of 10.10 being broken? (The article was written before 10.10.2 was released, so some bugs might have been fixed.) I think the only misguided part was to encourage people to replace system files.