DNS Resolving Broken
I'm using Arch Linux on a Linode 512. My network configuration was working fine recently, but, not now.
I did do a Linode resize recently, but I don't believe this caused the problem as I'd been able to do package installs up until a couple days ago. I mention this because someone seemed to have an identical problem to this caused by a resize, but it sounds like it was a problem with the resize and SELinux playing nicely together:
Here's the contents of /etc/resolv.conf:
8.8.8.8
8.8.4.4
Name lookups are broken, however, I can access the Internet just fine by IP address -
$ ping google.com
ping: unknown host google.com
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=8.18 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=8.56 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 8.187/8.376/8.566/0.210 ms
Anyone have any pointers? The following is some general networking information from my server (specific machine IP addresses removed) -
$ ifconfig
eth0 Link encap:Ethernet HWaddr FE:FD:45:A4:DD:19
inet addr:69.164.221.X Bcast:69.164.221.255 Mask:255.255.255.0
inet6 addr: fe80::fcfd:45ff:fea4:dd19/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:60260 errors:0 dropped:0 overruns:0 frame:0
TX packets:23681 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:54781503 (52.2 Mb) TX bytes:52366406 (49.9 Mb)
Interrupt:28
eth0:0 Link encap:Ethernet HWaddr FE:FD:45:A4:DD:19
inet addr:69.164.222.X Bcast:69.164.222.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:28
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:282 (282.0 b) TX bytes:282 (282.0 b)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
69.164.221.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
69.164.222.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 69.164.221.1 0.0.0.0 UG 0 0 0 eth0
3 Replies
nameserver 8.8.8.8
nameserver 8.8.4.4
Read 'man resolv.conf' >.<.
Also, why using Google's DNS instead of Linode's local ones, that are in same building as you are?
@rsk:
nameserver 8.8.8.8 nameserver 8.8.4.4Read 'man resolv.conf' >.<.
Also, why using Google's DNS instead of Linode's local ones, that are in same building as you are? Oh, man, stupid mistake on my part >.< I knew it was something simple. Thanks.
I had Linode's servers in there, but was fiddling with making the OpenVPN configuration bridged instead of tunneled and as a side-effect the dhcp client ended up clobbering my resolv.conf. Put Google's in there quickly since I knew the IP addresses.
@aaronfitz:
dhcp client ended up clobbering my resolv.conf
Switching to static configuration will solve that, see
--
Travis