0

I was given an API for a service through which I tried to send a post message from server A, but the connection cannot be built. Then I ping the domain name in the API. It doesn't work, so I thought it would be that the domain name had not been publicly mapped to the website.

To find the IP of the website, I pinged that in intranet from my client B, and then I used the IP shown in the message to replace the domain name and retried the post in server A. It didn't work. Then I mapped the IP to the domain name in /etc/hosts as a host entry in server A and used the domain name as the post uri, and it worked.

I wonder why it didn't work when I replaced the domain name with the IP address in the API? Does it only work by adding a host entry?

I am new to serverfault, then if this question is duplicated(I think it would be highly possible) please let me know. Thanks.

Lerner Zhang
  • 113
  • 5
  • `ping` is almost never a relevant troubleshooting tool. If you just need to resolve a name you can use any DNS client such as `dig`, `host`, or `nslookup`. – Patrick Mevzek Oct 15 '21 at 02:38
  • IF you use `curl` you can instead of an `/etc/hosts` entry (or other DNS fiddling like dnsmasq) use the commandline option `--resolve`; see the man page. And anything built on libcurl can have a similar option. – dave_thompson_085 Oct 15 '21 at 03:27

1 Answers1

0

Many webservers use the hostname that is sent in the request to determine which website should be used. This allows for multiple sites on the same IP.

So yes, correct hostname is often required.

NiKiZe
  • 1,246
  • 8
  • 20
  • 1
    Even "worse" than that: if HTTPS, the hostname has to be known even before HTTP traffic, that is with the SNI extension inside the TLS handshake. The server needs to get this information from client in order to be able to expose the appropriate certificate, without which HTTPS won't be as useful. – Patrick Mevzek Oct 15 '21 at 02:37
  • @PatrickMevzek true, browser always sends hostname (if browser supports SNI and requested by server) but the hostname sent will then be the ip address. – NiKiZe Oct 15 '21 at 06:11
  • 1
    "but the hostname sent will then be the ip address. –" No it won't, `N` in `SNI` means name... See §3 of RFC6066, it spells out clearly the extension is to be used for hostnames, nothing else. It says: " Literal IPv4 and IPv6 addresses are not permitted in "HostName"." – Patrick Mevzek Oct 15 '21 at 14:26
  • And this is for a simple reason: the server should already know on which IP address it was contacted by client, it doesn't need the client to send this information in another layer. On another hand, the server can not know with name resolution was done to reach that specific IP address, so the client has to send the **name** that was at the start of the process in a TLS extension early in the handshake for the server to make the appropriate choices based on that, like which certificate to present. – Patrick Mevzek Oct 15 '21 at 14:46
  • Thanks, I learnt something new today in regards to SNI. Standard HTTP/1.1 header still applies with Host where the host part of URL is sent regardless. So you can still have vhosts on IP (does not make much sense, but is possible) – NiKiZe Oct 15 '21 at 14:58
  • I never said you can't have virtual hosting on IP addresses, of course you can, see https://1.1.1.1/ for a famous example with a perfectly valid certificate. However those are edge cases (as are certificates for IP addresses, at least in HTTP world, they are far more "mainstream" elsewhere, like RPKI) and in general HTTPS URLs with IP addresses instead of hostnames are a bad idea/a sign of a problem somewhere (like later no certificate or invalid certificate, which should stop the client to connect). – Patrick Mevzek Oct 15 '21 at 16:01