I’ve now run into two scenarios where this happened. The most recent was after I had to kill a vpnc process (used to connect to a cisco VPN).
It looks like this:
[james@workstation ~]$ ping google.com ping: unknown host google.com [james@workstation ~]$ dig google.com +short 72.14.204.147 72.14.204.99 72.14.204.103 72.14.204.104
What ended up happening was that the VPN was configured to tunnel all traffic through it, so when it re-wrote the /etc/resolv.conf file, it didn’t append the VPN nameservers to the nameservers provided to us by our DHCP lease, but completely overwrote them. I’m assuming that when you closed the VPN it would replace the resolv.conf file with the one containing the non-VPN nameservers but since I killed it, it was not restored.
Anyway, the fix was easy but finding it out was annoying.
All you have to do is release and renew your DHCP lease.
You could try:
dhclient -r; dhclient
… but I was on an SSH connection and I didn’t quite trust the second command to be run after I lost the connection when the lease was released (this seems like a silly fear but whatever).
Instead I wrote a bash script and put it in a file:
#!/bin/bash
#refreshlease.sh
IFACE="eth0"
dhclient -r ${IFACE}
dhclient ${IFACE}
… and ran that over the SSH connection. The connection seemed to get dropped for a few seconds but then came back up. Checking /etc/resolv.conf showed that my original nameservers were, in fact, back and I was able to resolve DNS queries:
[james@workstation ~]$ ping google.com PING google.com (64.233.169.105) 56(84) bytes of data. 64 bytes from yo-in-f105.1e100.net (64.233.169.105): icmp_seq=1 ttl=238 time=31.1 ms
RSS Feed