CODEWITHSUNDEEP
nginxdnsdnsmasq
blueFast
blueFast

Reputation: 44511

Map DNS entry to specific port

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?

Upvotes: 3

Views: 8886

Answers (2)

Michael B
Michael B

Reputation: 12228

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

Upvotes: 3

Dominique Barton
Dominique Barton

Reputation: 918

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;
}

Upvotes: 4

Related Questions