Score:0

Why the IP cannot be used directly when the IP mapped to the host name as a host entry works?

ru flag

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.

Patrick Mevzek avatar
cn flag
`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`.
dave_thompson_085 avatar
jp flag
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.
Score:0
in flag

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.

Patrick Mevzek avatar
cn flag
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.
in flag
@PatrickMevzek true, browser always sends hostname (if browser supports SNI and requested by server) but the hostname sent will then be the ip address.
Patrick Mevzek avatar
cn flag
"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 avatar
cn flag
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.
in flag
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)
Patrick Mevzek avatar
cn flag
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).
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.