4 ms·

This article is at best misguided. OS X 10.10 DNS is not broken, it is working as intended - just differently from the past. Standards have changed and many h

This article is at best misguided. OS X 10.10 DNS is not broken, it is working as intended - just differently from the past. Standards have changed and many haven't noticed. 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 http://tools.ietf.org/html/rfc6762 Apple has also made this clear here: http://support.apple.com/en-us/HT203136 http://support.apple.com/en-us/HT203136 Yosemite has split the job of unicast and multicast DNS up such that you cannot resolve single-label .local domains with unicast DNS anymore; you MUST use multicast. This is why hosts will resolve with nslookup or dig but not ping. The old behavior with mDNSresponder was arguably legacy backwards compatibility for unicast DNS resolution of .local hosts. (I figured this out the hard way over a weekend using the Googles when my local VMs weren't resolving properly via dnsmasq - my fortunes changed when I looked into ".local"). There is one remaining problem with Yosemite DNS I haven't figured out yet, and that's getting unicast DNS resolution via dnsmasq while offline. Frustrating.

oe 12y ago
My Yosemite fails frequently resolving common domain names (.com). Has that something to do with .local domains and how could I fix it?
- nezza-_- 12y ago
  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.
- wolfhumble 12y ago
  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.
gurkendoktor 12y ago
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.
- deleted 12y ago
  [deleted]
jeffcox 12y ago
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.
- winthrowe 12y ago
  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 https://technet.microsoft.com/en-us/library/bb727085.aspx >
  - noinsight 12y ago
    Actually they've said different things about it: http://en.wikipedia.org/wiki/.local#Microsoft_recommendations http://en.wikipedia.org/wiki/.local#Microsoft_recommendation...
- jjoonathan 12y ago
  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.
- wvenable 12y ago
  .local doesn't work in Windows either as of Windows 8.
twoodfin 12y ago
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.
- IgorPartola 12y ago
  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.
  - ianlevesque 12y ago
    Or just `killall discoveryd` and let it relaunch on its own.
  - eridius 12y ago
    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.
    - IgorPartola 12y ago
      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?
smackfu 12y ago
>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.
- SG- 12y ago
  I haven't had or heard of anyone having DNS problems personally in 10.10 and I have quite a few clients using it.
janfoeh 12y ago
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
- silviogutierrez 12y ago
  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?
  - c0wb0yc0d3r 12y ago
    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.
  - ecnahc515 12y ago
    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.
  - janfoeh 12y ago
    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.
lectrick 12y ago
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
- parasubvert 12y ago
  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.
hackuser 12y ago
> 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 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.
FireBeyond 12y ago
"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.

oe 12y ago

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

nezza-_- 12y ago
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.
wolfhumble 12y ago
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.

gurkendoktor 12y ago

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.

deleted 12y ago
[deleted]

jeffcox 12y ago

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.

winthrowe 12y ago
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 https://technet.microsoft.com/en-us/library/bb727085.aspx >
- noinsight 12y ago
  Actually they've said different things about it: http://en.wikipedia.org/wiki/.local#Microsoft_recommendations http://en.wikipedia.org/wiki/.local#Microsoft_recommendation...
jjoonathan 12y ago
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.
wvenable 12y ago
.local doesn't work in Windows either as of Windows 8.

twoodfin 12y ago

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.

IgorPartola 12y ago
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.
- ianlevesque 12y ago
  Or just `killall discoveryd` and let it relaunch on its own.
- eridius 12y ago
  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.
  - IgorPartola 12y ago
    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?

smackfu 12y ago

>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.

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

janfoeh 12y ago

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

silviogutierrez 12y ago
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?
- c0wb0yc0d3r 12y ago
  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.
- ecnahc515 12y ago
  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.
- janfoeh 12y ago
  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.

lectrick 12y ago

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

parasubvert 12y ago
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.

hackuser 12y ago

> 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 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.

FireBeyond 12y ago

"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.