nslookup
and dig
. dig
, a much more powerful command, whose syntax is more crazy.make
or brew install dnsmasq
)dnsmasq.conf
file:resolv.conf
file that is in the same directory as the dnsmasq.conf
file (nb: not/etc/resolv.conf
):dnsmasq
with sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf
. The output should look something like:127.0.0.1
is the only DNS server (network preferences -> advanced -> DNS -> add 127.0.0.1)dnsmasq
without the --no-daemon
and --log-queries
options, so it will start in the background and you don't need to keep a Terminal window open./System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
and what I did was somehow interpreted as malformed. I restored from a backup and the machine was able resolve hostnames again.ssh -D
and tried DNS lookups through the tunnel.discoveryd
, was killed off as it was consuming too much CPU./System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
per @freezedpeanuts and @Tom Thorogood./System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
from the system image.sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
host
/nslookup
worked, both /etc/resolv.conf
and networksetup
reported the correct DNS servers, etc. Despite all that, DNS resolution in general (e.g. with ping
) inevitably stopped working at some point a few hours after boot.sensu-client
, specifically.-b
flag to sensu-client
makes it fork to the background, acting as a daemon. However, all launchd
sees is that the original process terminated, so (in accordance with the KeepAlive
flag) it restarts it. This leaves thousands of forked processes in the background, and even then launchd will be none the wiser to the fact that it is running.sensu-client
, the software we had written a launchd config for) may have been simultaneously making requests to mDNSResponder, effectively resulting in a local denial of service of the DNS cache. Killing these processes and fixing the plist given to launchd eventually solved the problem.-b
(background / daemonise) flag from the sensu-client invocation. Note that this is not sensu's fault; this plist was written by a former system administrator at this company.dig
to list the root name servers.dig example.com
to run DNS lookup for example.com
domain.networksetup -listallhardwareports
.ipconfig getpacket en0
.scutil --dns
.mDNSResponder
process is running by: ps wuax | grep mDNSResponder
.arp -ad
(run man arp
for help).sourcemDNSResponder
process, the following command may help:SIGINFO
signal to the process which will dump debugging details into log output which can be read and analysed./System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
file, and was the reason I had this problem./System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: No such file or directory
unkown-00-00-12-34-56-78.home
, which I've found is the MAC address of the server.I ran this in terminal: