Dear Lazyweb, how do I break the legs off of mDNSResponder?

NRPE starts failing to resolve hosts at random times, e.g., "check_nrpe -c some_command" returns "check_ping: Invalid hostname/address" while running the underlying check_ping command manually works fine.

So somehow being invoked from nrpe and/or launchd causes name resolution to work differently? Turning off mDNSResponder entirely with launchctl unload causes both nrpe and check_ping to not be able to resolve hosts, but host and nslookup still work fine.

Is it so much to ask that my machine should simply resolve hosts through plain old DNS instead of whatever-the-fuck crazy-assed games Apple is playing?

MacOS 10.6.8, NRPE 2.12.

Tags: , , ,

11 Responses:

  1. gryazi says:

    Have you poked at nsswitch settings until something works?

    I don't have any Macs nearby so this is a typical lazyweb response. I'm relying on the ancient history of to confirm that Darwin has a nsswitch implementation in the first place.

    Somehow I manage to make some machines play nice with mDNS c/o avahi, but the Linux implementation (which bears no real relation to anything AFAIK) required this mess:
    hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
    for some forgotten reason.

    • jwz says:

      10.6 does not appear to have nsswitch.

    • gryazi says:

      A related thought is that mDNS implementations are occasionally very phase-of-moon as to whether you'll get a IPv6 or IPv4 address - and ping is explicitly split into versions for ICMPv4 and v6 (and ping6 will still choke on link-local addresses unless you're explicit about which interface to try on, because having a default route for them would make too much sense, I guess?).

      • Nick Lamb says:

        On its own a link-local address has no global meaning. Providing a "default route" for them is just going to lead to mishaps. In an interactive diagnostic tool I can see a potential value in offering a sensible suggestion when the user isn't specific enough (e.g. "That's a link local address. Maybe try I -insert name of an Ethernet adaptor here-")

        One example of what will happen if you supply a default route is that the same lazy developers who wrote all those Windows drivers that assume the system is single processor, the X applications which assume 32-bit RGB is the only possible pixel layout, and so on will now assume that link local addresses don't require you to specify the link. Suddenly a whole pile of unnecessary bugs are created, just so you can type a few less characters on the rare occasion you use ping. (Despite their laziness, you just know these are the same developers who have a hand-rolled address parser so don't expect the built-in behaviour of getaddrinfo() etc. to save you from their mistake)

        • gryazi says:

          To shorten my knee-jerk reaction, this always smells more like {""gentle encouragement"" to make services globally-addressable with "real" addresses even when you're completely sure that's not what you want just now and would prefer to enjoy the fact that the same protocol was built to operate in both scopes if you ever change your mind} than protection from any specific evil demons.

          Possibly I am spacing out re: the syntax to allow you to specify the interface as part of the address so applications don't have to explicitly handle a separate "this is the interface that goes with my address" parameter.

          (Speaking of, has the Internet settled on a particular dead-tree IPv6 bible yet that actually covers the realities discovered once people started actually deploying it?)

      • Tony Finch says:

        Dual-stack weirdness is a Lion thing, I think - for some details see

  2. OSX does some wonky shit with DNS, and doesn't always set up the /etc/resolv.conf file properly when whatever db-based system they use changes. I usually see Safari working but not command line stuff as a result. This also screws up VPN for me as well.

    I've never been able to find a useable way to change DNS from the command line. I look forward to seeing if your minions have anything useful to add.

  3. Andreas says:

    OS X from Snow Leopard on wants you to use dscacheutil to do some of these things; at least it should let you run "dscacheutil -configuration" from the script to see what its idea of a resolver configuration is. Jup, it's a "Directory Service" utility, but it affects the DNS configuration, too. You just can't make this stuff up.

    • Pat Gunn says:

      Maybe it's come full circle; NeXTStep's DNS was pretty wonky, and if the system decided it was going to use NetInfo for name resolution, god help you. I understand that Apple fixed that stuff for a time, and now it looks like things have gone wonky again.

  4. Pierre Lebeaupin says:

    I don't know if that will be very useful to you, but when I find DNS wonkiness (e.g. Safari claims it cannot connect to the site, whichever the site, even though I can ping just fine) I just sudo killall mDNSResponder, and let it be restarted by launchd so that it starts from a clean state; it always fixes the issue (now that's what I call breaking mDNSResponder's legs).

    Note that even though its name comes from the multicast DNS feature (part of Bonjour/zeroconf), mDNSResponder also has the traditional DNS daemon/cache responsibilities and is part of the name resolution infrastructure of Mac OS X, there is no getting around it. As mentioned in their man pages, dig, nslookup and host are exceptions and do their own DNS queries over the network, but to the best of my knowledge there is no way for other processes to use the name resolution services of those; on Mac OS X I consider them only tools to troubleshoot the DNS server I'm supposed to use, they are not tools meant to query the Mac OS X name resolution process.

    (other processes that are useful to know when to kill are the Safari Flash Player sandbox whenever Safari appears stuck in a SPOD, and the Dock when none of Exposé, command-tab, and the Dock itself react. In the case of the Dock I always make sure to restart afterwards)