ping: unknown host in Centos 6.6 - dns

It's OK to ping IP address.
picture about ping and cat /etc/resolve.conf
I can ping 8.8.8.8, so the DNS server is OK to reach, and /etc/resolv.conf edited correctly. But I just can't ping domain. I've tried shutdown firewall but failed. Too strange, I used service iptables stop and iptables was still there.
Two problems:
1. unknown host
2. stop iptables failed.
Anyone can tell me how to fix these?

I solved this problem by accident and I don't know if it's copyable, but I need to write it down.
1. I set /etc/hosts to run command `yum install bind-utils`.
2. then, I run command `dig +trace www.baidu.com` to find out why ping fail.
then, miracle happens. I can ping domain again. The problem solved magically just as it occurred.

Related

Network Emulator (Netem) on Ubuntu 16.04

Hello I'm new to Linux,
I have a Linux VM with Ubuntu 16.04 loaded onto it. I'm trying to use a Network Emulator called Netem to delay packets.
However when I run the ping command after I put in the delay rule, there appears to be no delay. (see screenshot)
Screenshot of terminal
Below is my attempt at debugging the issue:
I know that usually there is eth0,eth1, etc. However when I run,
ifconfig there is no eth0 listed, just ens33.
So I substituted ens33 and ran the command below to add the delay.
sudo tc qdisc add dev ens33 root netem delay 350ms
Next I ping the VM to verify the delay has been added. But the result is the same as before the delay rule was added.
ping 192.168.126.130.
Can someone please give me input as to what my issue is?
Since you're running in a VM, your network device may not be eth0. If you're attempting to ping localhost, then it will be using the lo device since it's not trying to reach a remote network address. Try applying the rule to lo or ping a remote address.

gnome network manager: no internet, ping works, dig #8.8.8.8 works

Running opensuse tumbleweed with 4.7.5-1-default kernel and gnome.
Network managed with gnome's network-manager. Network (wired and wireless) connect to my router.
ping works also to external IPs
dig works if I provide the dns ip (eg. 8.8.8.8)
nmcli dev show | grep DNS shows the right nameservers (which I set in
the network managers interface): 8.8.8.8 and 8.8.4.4,
but dig without specification of the dns IP does not work
ping etc. to internet names (e.g. google.com) does not work.
Am completely lost by now. Help greatly appreciated.
(Matt stated the solution in his comment but I failed to understand it.)
Solution found on opensuse forum: the /etc/resolve.conf file was corrupted (empty). After deleting it and rebooting, the system (network-manager?) generated a new, working version. It contains the ip of the nameserver.

Why might my wget install of wordpress be failing?

I'm on CentOS 7. I'm running this command:
wget http://wordpress.org/latest.tar.gz
This is the returned output:
--2016-09-08 15:53:04-- http://wordpress.org/latest.tar.gz
Resolving wordpress.org (wordpress.org)... 66.155.40.250, 66.155.40.249
Connecting to wordpress.org (wordpress.org)|66.155.40.250|:80... failed: Network is unreachable.
Connecting to wordpress.org (wordpress.org)|66.155.40.249|:80... failed: Network is unreachable.
I'm not sure why that might be. I have access to my local network from my machine; I can install yum packages without issue.
EDIT
Result of ip route get 66.155.40.249
RTNETLINK answers: Network is unreachable
My /etc/sysconfig/network-scripts/ifcfg-eno16777736 after I edited it:
TYPE=Ethernet
BOOTPROTO="static"
IPADDR=192.168.2.100
NETMASK=255.255.255.0
NM_CONTROLLED=no
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=eno16777736
UUID=*random*
DEVICE=eno16777736
ONBOOT=yes
With the exception of my UUID... Specifically I added: bootproto, ipadder, netmask, and nm_controlled.
This situation happens when no entry in the routing table has been found.
If you're using a laptop (with wifi and ethernet) this may happen if you dhclient -r from one interface, which can remove the default route.
Easy resolution:
make a new dhcp request (optionally release the current lease)
add the default route by hand: ip route add default via <<GW ip>>. If you have several interfaces, you may need to specify the output interface using ip route add default via <<GW ip>> dev <<devname>> instead.

Docker DNS issue on local machine

I have an issue with Docker not resolving my local DNS. Running even a basic ping will no longer work. Current version 0.11.1 running on Fedora 20. The last time I worked with docker (version 0.9) everything was fine.
sudo docker run base ping google.com
ping: unknown host google.com
My local DNS is resolving fine outside of Docker and I don't have localhost (127.0.0.1) set in my resolv.conf file. I have also tried setting the dns with the same outcome:
sudo docker run --dns=8.8.8.8 base ping google.com
ping: unknown host google.com
Any help would be greatly appreciated.
If anyone else has this issue I got it working by clearing out the iptables:
iptables -F
For a more permanent solution after restarting I listed the iptables before and after flushing but couldn't really see what was affecting it. I ended up loading the Firewall Configuration, and enabling the Masquerade zone worked. Not sure why this setting had changed or if a change in newer Docker versions now needed this to be set, but it works. Interestingly I had previously tried just enabling IP forwarding (sysctl -w net.ipv4.ip_forward=1), but this had no effect for me.

cannot SSH beaglebone after changing

In order to get internet through USB from my ubuntu host, I changed routing on beaglebone
route add default gw 192.168.7.1
and change /etc/resolv.conf into
nameserver 192.168.1.1
It gets internet but I cannot ssh beaglebone like before anymore from any host.
Normally I did ssh root#192.168.7.2
but it doesn't return any message or prompt to enter password.Just blank waits there.
I there any way to fix it?
Are you sure that you shouldn't configure /etc/resolv.conf with
nameserver 192.168.7.1
It my happen that the ssh daemon is trying to resolve the reverse of the ip address you're connecting from, and it takes long to timeout, giving you the impression that it does not work.

Resources