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.
Related
In an Ubuntu 20 or 22 LTS, if I attempt to use a hostname like anyname.localhost it always seems to resolve to IPv6 ::1 address.
In an old RHEL 6, if I attempt to use a hostname like anyname.localhost it always seems to resolve to IPv4 127.0.0.1 address.
In a MS-Windows or MacOS 12.6 machine, this does not seem to happen. (It only happens if I manually edit /etc/hosts and manually add an host alias to 127.0.0.1
127.0.0.1 localhost localhost.localdomain somename.localhost
)
Is this any.sequence.of.names.localhost resolution to ::1 (localhost) always garanteed to happen ? By what reason ? In what Linux distros ?
I have a few projects where it seems useful to have many localhost aliases without having to edit /etc/hosts, but I searched about TCP and DNS quirks, and found nothing about this behaviour. (Not very sure what I should search for). Not sure if I can depend on this behaviour.
Well, thanks to the link posted in the comments above by Patrick Mevzek, I could reach a documented explanation.
For the Ubuntu 20/22 LTS, it seems to use systemd-resolved for DNS resolution.
And, as it says on
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
Synthetic Records
...
The hostnames "localhost" and "localhost.localdomain" as well as any hostname ending in ".localhost" or ".localhost.localdomain" are resolved to the IP addresses 127.0.0.1 and ::1.
So, this seems to explain that Linux OSes that have DNS resolution based on systemd will have this behaviour, and others (like Windows and MacOS) do not.
(So, this seemed a systemd question after all :-)
(This question is in fact a duplicate of https://serverfault.com/questions/1065513/how-does-linux-resolve-wildcard-locahost-subdomains-e-g-ping-test-localhost/1065514#1065514 - just using systemd-resolved instead of nss-myhostname , and if anyone knows how to link them both ways, could help others searching by other words).
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.
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.
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.
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?)