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!
Top Posts & Pages
-
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 [...]
[...] Configuration: TCP/IP Configuration for …Fixing OSX Lion DNS Search Domains | eigenspaceFix for broken search domain resolution in OSX Lion | Making It ScaleTechZinger: Apple OSX Lion Search Domains FIXWhat is the "Search Domains" field for in the [...]
Yeah nice but this also breaks mDNS, so no, not a fix but a hack just as dirty as apples original fuckup.
(byebye TimeMachine, iPhone WiFi-Sync, iTunes Sharing, …)
This fix has helped me and a bunch of our users since 10.7 came out. Here’s a simple script that seems to do what’s suggested above (on the few machines that I’ve tested it on):
#!/bin/sh
FILE=”/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist”
grep -q — -AlwaysAppendSearchDomains $FILE
rogramArguments: string \”-AlwaysAppendSearchDomains\”" “$FILE”
RC=$?
if [ $RC = 1 ]; then
/usr/libexec/PlistBuddy -c “Add
/bin/launchctl unload -w “$FILE” && /bin/launchctl load -w “$FILE”
fi
I’ve put together a shell script to automate the fix (and an uninstaller if you need it later), here:
https://github.com/michthom/AlwaysAppendSearchDomains
This was to give out to less-technical users at work that might shy away from manually editing system files.