Thanks to Erik for pointing this out, he has also put up a easy HOWTO for fixing this on his blog.
So it turns out all is not lost, you can still revert to the original behaviour of apples resolver! They’ve added a parameter to mDNSResponder called
-AlwaysAppendSearchDomains. Implying that this new behaviour was very intentional. I had read that Windows apparently made a similar change in one of there past updates as well so I guess this is to help fight some phishing attacks maybe? Either way, tres-annoying!
Anyway the gist of how to fix it is this:
Open up /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist and add
-AlwaysAppendSearchDomains following parameter to the list in the ProgramArguments block:
Then reload the launchd config for it, this should take care of restarting it as well:
launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
And…
icarus:~ bseibel$ ping util01.tor
PING util01.tor.verticalscope.com (67.223.104.5): 56 data bytes
YAY!
6 Responses to Fix for broken search domain resolution in OSX Lion
Leave a Reply Cancel reply
Categories
Follow me on twitter @brnseibel
- What's all this bright light at this hour? 1 week ago
- I'm starving and Exit41 can't keep their servers up. Bad move switching Swiss Chalet! 3 weeks ago
- Its a calm dry morning. I walk in the go station for coffee, walk out 2min later, torrential downpour and 40kmh winds? #wheredidthatcomefrom 2012-01-10
- More updates...
Recent Comments
- Mac OS X Lion loses network connection after sleep | info.michael-simons.eu on Fix for broken search domain resolution in OSX Lion
- Merlin Hartley on Broken search domain resolution in OSX Lion
- Scott on Fix for broken search domain resolution in OSX Lion
- Brandon Seibel on Broken search domain resolution in OSX Lion
- Jason on Broken search domain resolution in OSX Lion
Tags
a10 networks apache architecture backups bmw bottleneck broken search c cap theorem cpu customer service fable 3 facebook fallout new vegas freebsd fulltext gaming grails hardware latency lion mafia 2 mysql nat netapp network nfs orm performance php ports query planner rant scalability scaling search search domain servers sessions softlayer sphinx support twitter vbulletin zfs




Thanks! That’s one problem fixed. I am curious what security issue could have prompted this change though.
Now on to step two: how do I get 10.7 to lookup /etc/hosts entries before consulting the DNS?
That should still work, you may need to dscacheutil -flushcache though.
See here.
In short, with a search path, a DNS search for a particular site may inadvertently (or maliciously) be resolved by a reference at another site.
Say for example you have a DNS search path of “foo.com” because you want to be able to resolve the host “bar.foo.com” by just typing “bar.” So far, so good.
Well, what happens if someone creates a site “amazon.com.foo.com.” Yep, when you enter “amazon.com” into a browser, DNS will resolve it to “amazon.com.foo.com” if that host exists, and if that host happens to be a malicious site that mimics amazon.com… you get the idea.
Sure, but how many people add a search for a malicious users domain?
In reality the majority of people are likely using it within organizations to help with their ridiculously long internal domain names. And if someone is updating internal zones with malicious intent, well sounds like you’ve got bigger problems.
Thanks for the discussion and fix.
I am also having an issue in that
$ hostname -f
only returns the short name and not the FQDN. Any ideas?
[...] fixes to things: The domain resolution described here and the 2 hourly automatic wake from sleep described [...]