Fix for broken search domain resolution in OSX Lion

Update: It looks like as of Mavericks this doesn’t quite behave like it used to. It will still append search domains on lookups involving only a single domain level, however if you do multi-level look-ups like. it will not append any search domains. Looking through the mDNSResponder binary there doesn’t appear to be any new addition flags to change this behaviour :(

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


icarus:~ bseibel$ ping util01.tor
PING util01.tor.verticalscope.com ( 56 data bytes


18 thoughts on “Fix for broken search domain resolution in OSX Lion”

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

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

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

      1. Consider this scenario:
        I set up a WiFi access port in a crowded area or compromise an existing public WiFi router (not too hard). I add a search domain for malicious.com to the DHCP server. (As it happens, I have a wildcard cert for malicious.com.) I also use DHCP to point to a DNS server that has will return NXDOMAIN for bankofamerica.com. Finally, I add a DNS wildcard record pointing *.bankofamerica.com.malicious.com to my phishing server.

        The customer types in “https://www.bankofamerica.com” or clicks on his own bookmark, because he’s too smart to click on emailed links. He carefully checks for cert errors, because he knows they’re a big deal. Seeing no errors, what are the odds he carefully reads the value in the URL window? Slim and none. And he types in his credentials, and I’ve got them, and my phishing site does a little redirect to the actual BOA “you have mistyped your password” link and he continues none the wiser. Meanwhile, I’ve got his banking credentials and at my leisure I can go buy all the catnip I can snort. (Don’t you judge me!)

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

  4. 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, …)

  5. 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):



    grep -q — -AlwaysAppendSearchDomains $FILE
    if [ $RC = 1 ]; then
    /usr/libexec/PlistBuddy -c “Add :ProgramArguments: string \”-AlwaysAppendSearchDomains\”” “$FILE”
    /bin/launchctl unload -w “$FILE” && /bin/launchctl load -w “$FILE”

  6. I’ve been using this fix in Lion and Mountain Lion, but Mavericks made some other change and things are still broken after making this modification. I can resolve host1, host2, but if I try to resolve host1.region, it fails. This used to always work on Lion and Mountain Lion.

      1. I think i got it: you must do the modification to System/Library/LaunchDaemons/com.apple.mDNSResponder.plist as in lion but then unload & load both System/Library/LaunchDaemons/com.apple.mDNSResponder.plist and System/Library/LaunchDaemons/com.apple.mDNSResponderHelper.plist

        1. Well, finally got it to work in Mavericks. I put the wrong string in the plist file, I was missing the ‘-‘. Finally works now, I was ready to throw the Mac out the window.

Leave a Reply