10

This is a canonical question about hostname-awareness and proxying.

I know that some protocols are hostname-aware; that is, when I connect to the HTTP server at www.example.com it knows I want www.example.com's HTTP service, not www.example.net's, even though they are on the same IP address. How can I do this for protocol foo?

(Temporary note: this question appears pursuant to this meta discussion.)

MadHatter
  • 78,442
  • 20
  • 178
  • 229

1 Answers1

15

To understand what's going on, you need to know a little about DNS.

When a client wants to connect to a service on a given host, it looks up the hostname through its local DNS infrastructure, and receives an IP address in response. It then connects to that IP address, and requests the service in the manner prescribed by the procotol it's built to implement.

In some cases, part of that procotol involves a second sending of the hostname originally looked up, which in this case is sent to the server rather than the DNS infrastructure. In the case of HTTP, this was added as part of HTTP/1.1, in RFC 2616; in the case of HTTPS, this was implemented as Server Name Indication (SNI) in RFC 4366; and in the case of FTP, this was added by the HOST command, in RFC 7151 (but see later caveat). If such a second sending does not occur, the server has no way to know what hostname the client fed to its local DNS in order to get the server's IP address.

Note that in all cases a change to the protocol was required to do this second sending, and thus make the client-server interaction hostname-aware. After the protocol was changed, server code had to be updated to implement it. And finally, clients had to be updated to talk the new protocol to the servers. That last step can be particularly slow; in the case of SNI, Internet Explorer on Windows XP never implemented it, so the protocol could not be relied on while there was still any significant number of IE-on-XP users around, and it's taken about ten years for enough of them to die off and/or get upgrades that SNI is reliably deployable.

So that's what it takes to make a non-hostname-aware protocol hostname-aware. It is not a simple flag setting or configuration change. We have some protocol-specific answers that deal with the state of affairs, and possible mitigation measures, for that protocol in particular: for SSH (and thus also SFTP) and for FTP (which points out that HOST support for FTP is currently in the patchy-support phase, and so cannot yet be relied on).

The short answer is that if your protocol does not currently implement hostname-awareness, with good support amongst both clients and servers, forget it: it's not something you can do.

Community
  • 1
MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • 6
    I think I would temper this answer with the fact that some protocols are for brand-new products or are local enough that one company will control all instances of servers and clients. In those cases, simply adding hostname commands or packets is very simple and very easy to implement. You describe the difficulty in adding any new feature to an existing protocol that is already in wide use by many vendors. – JPhi1618 Oct 12 '17 at 15:40
  • 4
    @JPhi1618 I hear you, but in my opinion any "protocol" created and implemented by a single company, and *not* embedded in an RFC, is not a protocol at all; it's just an internal engineering decision, and I have no interest in such proprietary products. As you point out, the vendor can instantly change things to implement hostname-awareness if it so chooses; but since no-one *other* than the vendor can do that, I don't see how it's of much interest to the OP. – MadHatter Oct 13 '17 at 07:30
  • I think the relevant question is whether you're designing a new protocol, or asking how to change an existing protocol. – Barmar Oct 17 '17 at 18:51
  • A proprietary protocol is still a protocol. – Barmar Oct 17 '17 at 18:54
  • @Barmar that's probably not a good discussion to get into here. This question is about changing existing protocols, and as I noted earlier, if proprietary engineering decision / protocol `baz` can only be changed by its owner and sole implementor, then the only way to make it hostname-aware is to appeal to the owner. That doesn't make an interesting SF answer, and moreover is not (to my mind) on-topic. "*How do I design a hostname-aware protocol*" is another question altogether, and not one I'm interested in asking. – MadHatter Oct 17 '17 at 19:10
  • I don't see how any of this is relevant to serverfault. Server operators have to make do with the protocols as they exist, they don't have the liberty to redesign them. – Barmar Oct 17 '17 at 19:20
  • @Barmar have you followed the meta link at the foot of the question? In essence, you're right that this isn't possible, **but that doesn't stop people asking again and again how to do it**. Hence a *canonical* QA on the subject, so that all other copies of this question can be closed as duplicates. – MadHatter Oct 17 '17 at 19:23
  • I looked there, the question being proposed seems to be different from this one. It might be better if it were "Can I make a non-hostname-aware protocol hostname-aware, e.g. with a proxy?" And the answer will be "no". – Barmar Oct 17 '17 at 19:27
  • Exactly right, though it was felt, in meta, that it might be helpful to shed some light on *why* the answer was no. You're welcome to write your own answer, if you want (though you will find that "*no*" is too short to be an acceptable answer to the site engine). You can even write your own version of the question, though it may get closed as a duplicate! – MadHatter Oct 17 '17 at 19:28