ping google.com
ping: google.com: Name or service not know
Above is the error i am getting when using the ping command in CentOs 7.
Please share your thoughts what might be wrong here.
You can use nmtui to connect network, then everything will be fine.
From the issue you are facing,I can tell that DNS is not working and your machine is not able to resolve domain name.
One way to quick fix this issue is to run below command:
..# dhclient
..# ping google.com
dhclient-command reconfigures your network settings and it might require root priviledge to execute this command.
The results of both ping and wget indicate that your computer is unable to reach a DNS Server in order to resolve the hostname google.com. This isn't an error with ping, but rather a problem with the internet connection on your machine.
Try to ping the google name servers : 8.8.8.8 or 8.8.4.4. If this works your routing and basic networking is functioning if not https://www.networkworld.com/article/2693416/unix-networking-basics-for-the-beginner.html
i think that the first thing to try is
$ ping -c 3 localhost # -c 3 limits the number of pings to 3
if that produces a result something like this:
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.138 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.102 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.105 ms
then ping is installed and working in principle. if not, then the problem is either that your ether port is not active or connected (see other posts using 'nmtui' to set your port coordinates) or ping is either not installed or broken. in these latter cases i am not sure what to suggest.
Related
I created a docker container from the docker image centos:7, and started it through the following command:
docker run -h centos -it CONTAINER_ID
You can see that I gave it the hostname centos, so it should work if I ping the docker container from my host machine.
ping centos
Well, it didn't work. I got the following error.
ping: centos: Name or service not known
However, it worked if I changed the hostname to the IP address of the docker container.
> ping 172.17.0.2
PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.041 ms
64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.042 ms
64 bytes from 172.17.0.2: icmp_seq=3 ttl=64 time=0.037 ms
Since ip address is not as reliable as the hostname, I would like to know how I can ping my docker container via hostname.
If you want to reach your container via hostname, you need to add the respective IP in /etc/hosts on your host computer. As Docker does not modify anything on the host you have to do this manually.
echo "$(docker inspect --format '{{ .NetworkSettings.IPAddress }}' centos) centos" >> /etc/hosts
Instead I would advise to map the required container ports on the host (using -p <local-port>:<container-port>).
After new install of Ubuntu15.10 my commands(ping, ssh, ...) are using different IP address than one resolved by nslookup, host, dig, ...
How could this happen?
user#ubuntu-15-10:~$ nslookup foobar.com
Server: 127.0.1.1
Address: 127.0.1.1#53
Non-authoritative answer:
foobar.com canonical name = foobar.homeip.net.
Name: foobar.homeip.net
Address: 12.34.56.78
user#ubuntu-15-10:~$ host foobar.com
foobar.com is an alias for foobar.homeip.net.
foobar.homeip.net has address 12.34.56.78
user#ubuntu-15-10:~$ ping foobar.com
PING foobar.com (192.168.1.3) 56(84) bytes of data.
64 bytes from foobar.localdomain.home (192.168.1.3): icmp_seq=1 ttl=64 time=0.245 ms
64 bytes from foobar.localdomain.home (192.168.1.3): icmp_seq=2 ttl=64 time=0.285 ms
64 bytes from foobar.localdomain.home (192.168.1.3): icmp_seq=3 ttl=64 time=0.269 ms
^C
--- foobar.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.245/0.266/0.285/0.021 ms
user#ubuntu-15-10:~$
My /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
search localdomain.home
My /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat
group: compat
shadow: compat
hosts: files mdns4_minimal [NOTFOUND=return] wins dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
No entry for foobar.com in /etc/hosts
Anyone any idea?
I found a fix myslef after some investigation...
Problem was in /etc/nsswitch.conf:
at "hosts" line: "dns" entry should be before "wins" entry...
I don't understand what's behind, however now it works like expected
Sorry, the server configured is some strange fake server, probably at your own machine. The server address [127.0.1.1] is normally reserved for localhost interfaces (this is strange, as the localhost address is actually 127.0.0.1, and not 127.0.1.1)
The most probably cause you are receiving different responses is that nslookup(1) is a BIND utility to test dns access (it only uses dns lookups) and ping(1) uses the gethostbyname(3) library routine (which considers all possibilities configured in /etc/nsswitch.conf file for information on how to proceed, in this case, being the dns part the last resort)
On other side, the actual address of host foobar.com is not that one (see below).
Finally, the address foobar.com resolved by ping(1) as shown in your output is one private address (not the actual one, see RFC-1918), you cannot find that host over internet.
The most probable thing is that you have not asked for dns resolution to any official internet nameserver, so everything is a matter of local dns configuration.
Possible causes of the difference:
mdns4_minimal is some fake program that doesn't ask the actual nameserver.
dns is the last option in the /etc/nsswitch.conf, so official DNS protocol goes last (when all other protocols have failed)
your dns is not listening in address 127.0.1.1 and you have some ssh port redirection or tunnel to someother nameserver giving the wrong answers. The address 127.0.1.1 is normally used by the tap* network device when used for example to configure openvpn(1) client connections.
You have not shown the nameserver config files running at your machine. Perhaps the origin of the address you get is there. Look for named(8) config files and search for the domain foobar.com in those config files.
None of the addresses you shown is a real internet address (127.0.0.0/8, 10.0.0.0/8, 172.16-31.0.0/16, 192.168.0-255.0/24 and 169.254.0.0/16 are all reserved internet addresses for one or other reason, and you won't see any of these addresses appearing on packets coming from internet) The reasons are diverse, but the fact is that all your traffic is local in your private network and nothing, except perhaps the nameserver running at your machine has internet access.
Sorry but with the information you provide, this is the only I can argue to try to solve your error.
Something you can do is the following (to get a clean dns resolution):
configure dns after files in /etc/nsswitch.conf. This will give dns priority before that mdns4_minimal and wins resolution)
configure nameserver <ip> with the actual addresses of your nameservers (They should be communicated to you by your internet provider. If you don't know what to put there, just try nameserver 8.8.8.8 which means use the google nameserver to solve addresses. Fortunately, it is open to everybody)
These steps will make dns resolution to overpass your local nameserver completely and you'll get something like
$ nslookup foobar.com
Server: 46.183.73.1
Address: 46.183.73.1#53
Non-authoritative answer:
Name: foobar.com
Address: 69.89.31.56
$ ping foobar.com
PING foobar.com (69.89.31.56): 56 data bytes
64 bytes from 69.89.31.56: icmp_seq=0 ttl=50 time=173.196 ms
64 bytes from 69.89.31.56: icmp_seq=1 ttl=50 time=175.091 ms
64 bytes from 69.89.31.56: icmp_seq=2 ttl=50 time=208.612 ms
64 bytes from 69.89.31.56: icmp_seq=3 ttl=50 time=177.145 ms
^C
--- foobar.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 173.196/183.511/208.612/14.559 ms
$ _
If you have installed ubuntu and didn't configure internet connection at installation, the most probable cause is that it has configured dns locally with a fake database that allows you to make experiments, before configuring it for real internet access.
On windows:
Accessing _.github.com in the browser works
nslookup _.github.com works
ping _.github.com works
On linux (tested on two separate networks):
Accessing _.github.com in the browser works
host _.github.com works
ping _.github.com does not
python -c "import requests; requests.get('_.github.com')" does not
What is going on here?
Because Linux (more specifically, some component of it such as libresolv or even ping itself) is honoring the RFCs. Underscores are not allowed in hostnames, and a hostname is what you are looking up when using ping. (Underscores are allowed in other types of DNS records, for example SRV records, TXT records such as those used for DKIM...)
See RFC 1123 section 2.1, and RFC 952. Here are some other links to discussion of this topic:
Stack Overflow - Can (hostname) subdomains have an underscore “_” in it?
Domainkey - Underscores in DNS
Quora - Why are underscores not allowed in DNS host names?
Update: As a couple of people pointed out in comments, Linux ping is happy with a_a.github.com. Doing a few more tests (CentOS 7 in this case):
ping: unknown host _.github.com
ping: unknown host a_.github.com
ping: unknown host _a.github.com
$ ping a_a.github.com
PING github.map.fastly.net (23.235.40.133) 56(84) bytes of data.
64 bytes from 23.235.40.133: icmp_seq=1 ttl=59 time=29.7 ms
So it seems Linux ping does not reject the underscore completely, but it does appear it disallows it being the first or last character (or, as a consequence, the only character) in an atom of the hostname.
On host machine, it's very fast to lookup a domain. But inside docker container, it's much
slower and sometimes timeout.
The host machine is a virtual host, and it's dns server address is 127.0.0.1 (weird but true). So I've tried to modify /etc/resolv.conf inside container and set the dns server to be 172.x (host's address). As a result, I didn't see any good effect.
I've also tried to set the container's dns server to be a self-built one (101.x), but still, it's slow to look up a domain. Another weird thing is that ping 101.x is very fast.
I'm confused about this phenomenon, anyone can explain and help?
I am not sure of why resolving DNS is slow in the containers, but I have procedure which I follow to resolve the DNS in the docker containers.
To verify DNS resolution issue:
# docker run busybox nslookup google.com
Server: 8.8.8.8
Address 1: 8.8.8.8
nslookup: can't resolve 'google.com'
Find out the DNS server used in your machine :
# nm-tool |grep DNS
DNS: 172.24.100.50
DNS: 10.1.100.50
Run it again using DNS IP found in the above step which resolves the DNS issue:
# docker run --dns 172.24.100.50 busybox nslookup google.com
Server: 172.24.100.50
Address 1: 172.24.100.50 indc01.radisys.com
Name: google.com
Address 1: 2607:f8b0:4009:80c::200e ord36s01-in-x0e.1e100.net
Address 2: 172.217.4.110 ord36s04-in-f14.1e100.net
To resolve it permanently add the following content as below to a new file:
root#labadmin-VirtualBox:/home/labadmin# cat /etc/docker/daemon.json
{
"dns" : ["172.24.100.50", "8.8.8.8"]
}
More info on Docker DNS configuration.
Restart the docker service and verify it again:
# docker run busybox nslookup google.com
Server: 172.24.100.50
Address 1: 172.24.100.50 indc01.radisys.com
Name: google.com
Address 1: 2607:f8b0:4009:801::200e ord30s31-in-x0e.1e100.net
Address 2: 172.217.4.238 ord30s31-in-f14.1e100.net
Check it by running the container:
# docker run -it e02e811dd08f
/ # ping google.com
PING google.com (172.217.4.238): 56 data bytes
64 bytes from 172.217.4.238: seq=0 ttl=47 time=251.506 ms
64 bytes from 172.217.4.238: seq=1 ttl=47 time=245.621 ms
Hope this helps.
I have installed apache2 in my ubunntu 12.10 system with inet addr 172.16.17.235 and inet6 addr fe80::a05b:25ff:fef0:68a4/64 in LAN.
Now when i want to open default website (index.html) located in /var/www/ , i simply write http://localhost or http://127.0.0.1 or http://172.16.17.235 in my web browser(firefox 17.0) and it opens that index.html page
but when i want to access this index.html with the help of ipv6 addressing as below :
http://[::1] orhttp://[fe80::a05b:25ff:fef0:68a4]
following error is shown by browser :
Unable to connect Firefox can't establish a connection to the server at [::1] or
Firefox can't establish a connection to the server at [fe80::a05b:25ff:fef0:68a4].
Can any one tell me what configuration am i missing in my system or what i am doing wrong.
BTW when i ping to my localhost as :
ping6 ::1 or ping6 -I eth0 fe80::a05b:25ff:fef0:68a4
ping reply is coming fine as : 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.032 ms or
64 bytes from fe80::a05b:25ff:fef0:68a4: icmp_seq=1 ttl=64 time=0.048 ms
If you want to use an IPv6 address from the fe80:: range, you must specify over which network adapter it should go. (Technically, you must provide the Zone ID which correlates with the network adapter used).
On ping, you do that with -l eth0. In Firefox, you can do that with http://[fe80::a05b:25ff:fef0:68a4%x] where x is a positive number you must find out.
EDIT: If you absolutely don't find out what is going on, you could try this:
python -c 'import sys,socket; print socket.getaddrinfo(sys.argv[1], (sys.argv[2:]+[0])[0], 0, socket.SOCK_STREAM)' fe80::a05b:25ff:fef0:68a4%eth0
and have a look to the result. On my system, it looks like
[(10, 1, 6, '', ('fe80::a05b:25ff:fef0:68a4%eth0', 0, 0, 3))]
where the last number, the 3, is the real Zone ID.
If this gives you a result, your name resolution works fine, if not, it is broken.
The next step could be to try to create a HTTP connection:
python -c 'import sys,socket; c=socket.create_connection((sys.argv[1], 80)); c.send("GET / HTTP/1.0\n\n"); print c.recv(100000).split("\r\n\r\n",1)[0]' fe80::a05b:25ff:fef0:68a4%eth0
If that works, the problem is your browser, if not, you cannot reach the server due to whatever reason. (Does your web server daemon bind to IPv6?)