I'm planning on buying two domains.
Let's say they are domain1.com and domain2.com.
I will point them at two custom servers that I have on my computer, both of them having an HTML "browsable" endpoint.
I want to know if it's possible to point domain1.com to mycomputer:12345 and domain2.com to mycomputer:9876, so when you open, for example, domain2.com with your browser, it redirects the traffic to mycomputer:9876, without writing explicitly domain2.com:9876.
I've been searching for information about DNS records and reverse proxies, but I'm unable to figure out a way to achieve this, or something close to it.
Thanks for your time.
You can achieve this by using a reverse proxy server eg. nginx.
All you need to do is configure each domain to to the appropriate server and port in the nginx config.
Just for your information - At DNS level you can't mention ports, as DNS servers doesn't carry port information.
Related
Let's say I have this DNS entry: mysite.sample. I am developing, and have a copy of my website running locally in http://localhost:8080. I want this website to be reachable using the (fake) DNS: http://mysite.sample, without being forced to remember in what port this site is running. I can setup /etc/hosts and nginx to do proxing for that, but ... Is there an easier way?
Can I somehow setup a simple DNS entry using /etc/hosts and/or dnsmasq where also a non-standard port (something different than :80/:443) is specified? Without the need to provide extra configuration for nginx?
Or phrased in a simpler way: Is it possible to provide port mappings for dns entries in /etc/hosts or dnsmasq?
DNS has nothing to do with the TCP port. DNS is there to resolv names (e.g. mysite.sample) into IP addresses - kind of like a phone book.
So it's a clear "NO". However, there's another solution and I try to explain it.
When you enter http://mysite.sample:8080 in your browser URL bar, your client (e.g. browser) will first try to resolve mysite.sample (via OS calls) to an IP address. This is where DNS kicks in, as DNS is your name resolver. If that happened, the job of DNS is finished and the browser continues.
This is where the "magic" in HTTP happens. The browser is connecting to the resolved IP address and the desired port (by default 80 for http and 443 for https), is waiting for the connection to be accepted and is then sending the following headers:
GET <resource> HTTP/1.1
Host: mysite.sample:8080
Now the server reads those headers and acts accordingly. Most modern web servers have something called "virtual hosts" (i.e. Apache) or "sites" (i.e. nginx). You can configure multiple vhosts/sites - one for each domain. The web server will then provide the site matching the requested host (which is retreived by the browser from the URL bar and passed to the server via Host HTTP header). This is pure HTTP and has nothing to do with TCP.
If you can't change the port of your origin service (in your case 8080), you might want to setup a new web server in front of your service. This is also called reverse proxy. I recommend reading the NGINX Reverse Proxy docs, but you can also use Apache or any other modern web server.
For nginx, just setup a new site and redirect it to your service:
location mysite.example {
proxy_pass http://127.0.0.1:8080;
}
There is a mechanism in DNS for discovering the ports that a service uses, it is called the Service Record (SRV) which has the form
_service._proto.name. TTL class SRV priority weight port target.
However, to make use of this record you would need to have an application that referenced that record prior to making the call. As Dominique has said, this is not the way HTTP works.
I have written a previous answer that explains some of the background to this, and why HTTP isn't in the standard. (the article discusses WS, but the underlying discussion suggested adding this to the HTTP protocol directly)
Edited to add -
There was actually a draft IETF document exploring an official way to do this, but it never made it past draft stage.
This document specifies a new URI scheme called http+srv which uses a DNS SRV lookup to locate a HTTP server.
There is an specific SO answer here which points to an interesting post here
Note: “VirtualHost” is an Apache term. NGINX does not have Virtual hosts, it has “Server Blocks”. (https://www.nginx.com/resources/wiki/start/topics/examples/server_blocks/).
I know about ip-based and name-based server blocks, but is it possible to have URL-based server blocks? In other words, I want http://example.com/foo and http://example.com/bar to be served from completely independent roots. This would be a trivial problem to solve with name-based server blocks if the names were different http://example1.com and http://example2.com, but since the names are the same (example.com) and only the path part of the URL is different... Can nginx support separate server blocks for these types of URL's?
See https://nginx.org/en/docs/http/request_processing.html
It seems the only options available are: IP address, port, host, and if none of those match, then it serves the default server. So, given that the name and port are the same in both cases, the only possible solution is to put a proxy server in front of nginx, and have the proxy server distribute to the backend nginx server using a different IP or port.
I have a play application running on port 8080. I currently forward to this by using
http://ip_address:8080
as my 'URL to forward to' in my forwarding service control panel.
The problem with this is: frame forwarding is used and I think this may be stopping Google Analytic for working.
I have control over DNS
A, CNAME, AAAA, TXT and NS records
&
DNS Service records
For other websites in the past running on port 80 I have simply created an A record with the destination as the server IP address, however because I am using port 8080 in this case, this does not work.
What is the best way to go about getting away from framed forwarding?
You can't put port numbers into the DNS resource record (there's a notable exception, namely SRV records, but as client support for those is rather spotty, those won't be much help). A nameserver commonly resolves hostnames to ip addresses - no directory/file names, no port numbers.
You can use a permanent redirect, which is a webserver facility, used to tell web clients to contact a different webhost. In order to use that, you need a webserver which responds to requests on port 80, and knows that requests concerning your zone must be redirected to your actual webserver. Very similar to the iframe solution you've been already using, but a permanent redirect instead of iframe.
If your reason for dropping the current iframe approach isn't that you, for example, want to get rid of decorative framing, ads, "branding" etc (with those, a permanent redirect would help), but want to cease using an intermediate webserver, adding another level of indirection to the queries, there's little you can do:
your firewall may be able to do port redirection, meaning that the incoming requests will hit your gateway/firewall on port 80, where the request is sent on to port 8080 where the webserver is actually listening. Another possibility could be, but requiring again another webserver, listening to port 80, to set up proxying: incoming requests to that webserver will be served from a cache on that server, which is populated and occasionally refreshed as result of that webserver querying your webserver on port 8080.
Even though with the latter suggestion an additional webserver will be existing, there'd be no visible indirection, as it would be transparent to clients: The web files are produced by the first server which is hit, even if they are once every so often taken from another server.
I simply want both example.com and www.example.com to go to the same website. Currently we have just added a binding to each. This creates a problem for WCF which then breaks because it says it can only accept one http address.
Is there a better way to configure a site to accept addresses with or without 'www'?
this has to be changed in the dns using a host or a record.
You shouldn't be hosting a site on the root domain. Better approach here is to redirect traffic to the root (.example.com) to the correct site (www.example.com) using an HTTP 302.
The WCF service should only receive traffic on its single binding. Use DNS, HTTP redirection, or some Traffic management application/appliance to get traffic from multiple points to the correct one.
I am trying to get around ISP limitations of 1 IP address. Here is what I am trying to do. I have two web servers running internally on my network. One is my main IIS box that runs 4 or 5 sites and I just added a windows home server. I have created a dns entry for it called home.mydomain.com and the other server reponds to www.mydomain.com.
My router is set to forward 80 to www.mydomain.com's server (192.168.1.3) so when requests come in for home.mydomain.com the request fails since www server is not set up to listen to that host header.
I would like to know if there is a way with IIS 7 to 'proxy' requests to home.mydomain.com (192.168.1.4). I had tried setting up HttpRedirect in IIS but that does not work as I would have hoped since it sends back a 302 to the client with a name that points back to the main IP address and then a vicious redirect loop happens.
I am told in apache this can be done by having one server proxy for the other. Can this be done in IIS 7? If not does anyone know of a webserver proxy type of software I can use?
Thanks in advance,
Rich
What you are looking for is a "reverse proxy". In Apache you can do this via mod_proxy. In IIS, you'll want to try the Application Request Routing package.
URL Rewrite for IIS can also be used to do reverse proxing.
Yet another reverse proxy package is Managed Fusion URL Rewriter and Reverse Proxy