This is a Canonical Question about DNS/Hostnames resolution to IPs/Ports
Example 1
I'm running a web server on port 80 and another on port 87. I would like to use DNS so that www.example.com goes to port 87. How can I accomplish this using DNS only?
Example 2
I'm running a service on my server on a non-standard port. How can I get clients to connect to this non-standard port automatically? Can I use DNS? Is there some application specific support where DNS could indicate the IP and Port?
Example 3
Do some application protocols specifically support hostname awareness, and allow special actions to be taken based on this information? Are there other questions on Server Fault that cover some of these?
Commandeering:
This question was originally asking about running IIS and Apache on the same server, but the same concepts can be applied to any server software receiving connections from clients. The Answers below describe the technical problems and solutions of using DNS and application protocol support to assign a port number for a client to connect.
You cannot use the DNS to point to a port (unless the client supports SRV records, most don't).
Websites and Protocols with Host Headers
You will have to put some front-end method in place to do this. Typically you would use a front end web server or a dedicated proxy software to forward the connection from port 80 to port !80 based on the name of the server being requested in the header. Some firewalls can also forward based on the host header too.
SRV Records
Some clients support lookups of SRV records which indicate hostname and port number of server for the specified service (ie the user specifies "example.com", the client looks up a SRV record and gets "server101.example.com" on port "255"; then connects to that). Some clients also implement this where it is not required (my last smartphone would lookup the SRV records when setting up a new e-mail account for example).
Unfortunately support for SRV records is highly uncommon. Only a few notable protocols mandate it's support (Jabber/XMPP, Kerberos, LDAP, SIP) and not every client supports it even when mandated.
When you type http://www.domain.com into your browser, it is understood that the HTTP port is on 80. Therefore, there is no direct way to point www.domain.com to port 87 if you already have a service running on that port in IIS.
That being said, there are a few "workarounds".
Sam is right, DNS is agnostic when it comes to ports. Any sort of port redirection happens by the service that is running on that port. Therefore you would need to do something with IIS to make this happen, if you have no choice but to leave it on port 80.
I've also gotten around your situation by using mod_proxy on Apache, not sure if there is a way to do this with IIS.
Technically you can use SRV records on DNS servers as defined in RFC 2782 to tell browsers which servers handle http on which ports for a (sub-)domain:
This works well for many protocols/services, especially where the usage of SRV records is already defined in the protocol specification.
However as this "Hall of Shame" states, most of the web browsers/clients do not support this (for HTTP). Also see why-do-browsers-not-use-srv-records.
The deal is basically, that SRV is not included in the http protocol as a must so every browser that implements it resolves URLs differently than browsers that don't.
So you should only use this as some optional load balancing, where it is not relevant which server is chosen in terms of content. "Optional" because it won't balance much of the load if only few clients implement this.
I'm afraid domain names can only be associated with an IP address and not a port.
Most web servers e.g. (Apache, IIS etc.) do allow you to have two domains hosted on the same IP address by using the fact that web requests contain a host-header field that identifies the domain in the request itself.
If you say what the web server is that you are using I'm sure people can point you to the relevant documentation to set up your server as you wish
DNS does not have the capability to redirect to a specific Port, all DNS cares about is the IP address resolution of a name, and vice versa.
Some services, such as Dynamic IP DNS providers, such as NO-IP provide a serivce that can help you do something similar to get round blocking of IP's on home DNS services.
In order to use any (TBT) service on non-standard port and don't write port in URI, everybody can use SRV records, defined in RFC 2782.
All other http-hosts in zone still will be served on default port 80
The simplest way is using a reverse proxy and setting it as your web proxy. You can configure a
nginx
orapache
for it. I had basically the same problem in the past and made a tool to achieve such configuration in a simple way. Ergo: https://github.com/cristianoliveira/ergoI have been using this and basically, works like a charm :)
One approach to deploy two web servers on the same host is to have both of them listen on port 80 on two different IPv6 addresses. IPv6 officially specify that you can assign two addresses to an interface, and there are enough IPv6 addresses that you can do this without running out of addresses.
This is future proof, and your two domains can each have AAAA records pointing to the different IP addresses, so the domains end up at different web servers.
If you have a single IPv4 address as well, you can use port 80 on the IPv4 address to run a reverse proxy. That way IPv4-only clients can access both your web servers. The reverse proxy approach even works if some of the web servers are on the same host as the reverse proxy and some of the web servers are on other hosts.
In such a setup
example.org
could have addresses192.0.2.1
and2001:db8::1
whileexample.net
has addresses192.0.2.1
and2001:db8::2
.I am not aware of the technical details but how I resolved this issue is by creating a CloudFront distribution that points to the specified HTTP port.
Then with Route 53, I pointed to the CloudFront distribution.
While the mentions above make very clear that DNS records are port agnostic (except for SRV records -- that are not incorporated in most clients); there is a possibility: to use URL forwarding services that are offered by most DNS providers (eg. easyDNS)
This will allow you to make easier for the user:
so from your exemple www.example.com goes to port 87, with this service you can config http://www.example.com to reach http://www.example.com:87 (basically the user that has only the domain, will be able to reach your site); you can also use this for making a call to a regular http protocol resolve to https://www.example.com:87, or even to point to some subpages as https://www.example.com:87/dologin
The IPV6 solution of @kaperd seems perfect, but while I was able to configure the server properly, I did fail open the target on Chrome... maybe it need some twerking and I did not spent enough time.