Short Question:
Is it possible that example.com points to an IP address, but example.com/something points to another IP?
More Details:
example.com was previously hosted with my client's host company. I have designed a new website for them and now host it myself (by pointing their IP to mine). They are now letting me know that there used to be a sub-directory where another application was hosted under. It would take me a while to re-install that application in the new host, I was just wondering if it'd be possible to serve any request to that sub-directory through the old host/IP.
That's not possible. Resolving the host (example.com) is a separate task (DNS query) from connecting to the http server (HTTP connection) that the host points to. None of the URL, except for the hostname, is queried via DNS so there is no way that DNS can be made to behave differently based on other parts of the URL as it doesn't see it.
A subdomain is part of the hostname and that's why www.example.com and www1.example.com can point to different addresses. If you need to have www.example.com/something go elsewhere, you'll need to use HTTP redirects.
Related
I have a web application with a Vue front-end and Golang back-end.
I am trying to deploy the front-end static files on local work network.
I am serving them with http-server on a windows server connected to the network.
Rightnow if I execute
http-server -p 50
I am able to access the application by going to http://hostname:
50
However, the goal is to deploy it on
http://hostname/app
Is it possible to do it, if so what would be the approach in terms of best practices.
Note: For deployment of the Vue static files either a node server or golang server would work.
Let's start with a bit of terminology correction.
http://hostname is not really a domain. It is just a URL referring to
an unqualified host name. A domain would typically be something like
yourorgdomain.com (or .org or .edu or other such top level domains;
let's stick with .com for now). Your hostname (when fully qualified
under the domain) would be identified as hostname.yourdomain.com.
Therefore, your hostname is mapped to a subdomain. For the sake of
simplicity, if being referred from another host on the same domain
and network the domain part is implied so the network understands that and something like http://hostname just works. The mapping is somewhere
in your network configuration.
http://hostname/app is not a subdomain of http://hostname; it's just
a path (or more correctly a resource) under the same host http://hostname. A subdomain would be something like http://app.hostname http://app.hostname.yourdomain.com when fully qualified)
Now for some explanation of how these URLs work:
Consider the URL http://hostname:50. The http:// part is referring to the protocol and :50 part at the end to the port number. By default http uses port 80 (https uses 443). So if you configure your web server to serve on port 80, the :50 part is redundant.
Now you just need to organize your website content such that it is available at http://hostname/app URL. The simplest way to do this for static sites is to host your content under the /app/... directory relative to where your site root is mapped to. So if your web server is serving the directory .../public on http://hostname, just move your content to .../public/app like you do for file paths. That's all
Caveats
However, if you truly want to host your app under a subdomain like http://app.hostname/ then that's a whole different story, but in brief, the lowest level subdomain being referred to (app) has to be mapped to a host and the intermediate subdomain can't be a host, just a subnet. You can't have further subdomains under a host. That's why typically websites addresses refer to http://www.example.com where the www is mapped to the host actually running the website
All of this ignores how reverse proxies and load balancers work and pretend to exhibit this above behavior but that another long story for another day.
I have 1 single machine with an IP 1.2.3.4. This machine has 2 web servers and an ftp server:
Web Server 1 listens to port 82; the domain for it: ws1.example.com
Web Server 2 listens to port 83; the domain for it: ws2.example.com
FTP Server listens to port 21; the domain for it: ftp.example.com
This is what the DNS mapping looks like:
ws1.example.com CNAME example.com
ws2.example.com CNAME example.com
ftp.example.com CNAME example.com
example.com A 1.2.3.4
Case 1: I make a request at the browser URL ws1.example.com:82 and the DNS redirects me to example.com but with the Host header: ws1.example.com.
Case 2: I make a request at the browser URL ws2.example.com:83 and the DNS redirects me to example.com but with the Host header: ws2.example.com.
In both the cases:
the request ultimately reaches the same physical machine
when the request arrives:
In Case 1, the request arrives at this machine and the request is attended to by the application that is listening on port 82 i.e. Web Server 1.
In Case 2, the request arrives at this machine and the request is attended to by the application that is listening on port 83 i.e. Web Server 2.
The Host header, as I understand, is used to inform the receiving host to identify which server (from the multiple servers that this IP has been hosting) is this request meant for and accordingly directs the request to the appropriate application.
My question is:
In this example, what is the purpose of the Host header as the same physical machine with the same IP has multiple applications listening at their corresponding ports. Once the request reaches this machine, the appropriate port will anyway pick up and the other applications will ignore the request as the port does not match the request. So, what purpose is the Host header serving here when apprpriate ports are anyway doing their job, right and well?
Can I infer that
CNAMES
Multiple Web Servers behind a single IP
subsequent resolution of a particular user request to the appropriate Web Server with the Host header
make sense only when you are using something like a Reverse Proxy e.g. 1 machine interfaces with the client and redirects user requests to the appropriate web server on separate machines all listening on the same port e.g. 80, each in the network behind the reverse proxy in which case you have ws1.example.com and ws2.exmple.com both be redirected to the reverse proxy example.com and this reverse proxy now forwards it to the appropriate host based on the Host header?
No DNS redirections
First an important terminology fix:
There are no "redirects" in the DNS. In your case, the DNS is just use to map a name to an IP. Sometimes, because of CNAME, a name is mapped to another name which is then mapped to an IP. It does not matter if there are intermediate steps like that, at the end a name maps to an IP (or there is a DNS resolution failure)
This also means that if the URL has a specific port, then that is not changed, the final IP will be queried over the port mentioned in the URL.
Redirections are an HTTP level feature: when querying a webserver for https://www.mygreatsite.example/foo it will reply with an HTTP return code of 301, 302, 303, 307 or 308 and giving you (the HTTP client, aka the browser) the new URL to go to.
HTTP virtual hosting
In the good old days, IP addresses were plenty. If you were hosting both www.site1.example and www.site2.example on the same physical box you could attach one different IP address to each.
Hence, in that specific case, in a way, the HTTP host header is useless, the mere fact of connecting either to 192.0.2.37 or 192.0.2.42 already lets you know which site you want.
In fact in HTTP/0.9 there was no host header, as there were no headers at all.
But then, with mass virtual hosting coming into play, and IPv4 addresses becoming scarce, you could not anymore attach one single IP address per site, since it was also a waste.
So you had, through the DNS, either directly or indirectly (CNAME records), both websites resolving to the same IP.
Hence when the HTTP client connected to the server, the server by default has no way to know which website do you want. That is why the HTTP host header filled by the client lets the server know which website you want to access, irrespective to its IP address, that was resolved earlier through the DNS.
By default HTTP uses port 80, so it is often not visible in the URLs.
Of course if you forced your clients to use http://www.site1.example:4569 on one side and http://www.anothersite2.com:9873 on another side, then you are right the host header would not be really needed.
Except that the plan falls down for many reasons:
Port numbers are not an infinite space either and many of them are already used typically for other things; so even if you extend this scheme at one point you could not attach new websites to the same IP
But more important than the previous technical point, for humans this will be a nightmare and many people will use forget the port number and then not coming to the appropriate website.
Hence typically it is not done like that, if you want to expose some given service over HTTP but in a non default port you typically install a reverse proxy in front of it. Or you do an HTTP redirection from http://www.coolpublicname.example/ to http://www.complicatedinternalname.example:9713, but then the client sees this naked truth.
HTTPS virtual hosting
In passing note that HTTPS added a level of complexity because the HTTPS webserver needs to send its certificate to the client, but since each website can have a different certificate it needs to know which website the client wants to use, which it could learn through the host HTTP header but then comes after the TLS handshake is finished, so in the early stage of the server sending a certificate this is not available yet.
So at the earliest times of HTTPS we were forced again to do IP-based virtual hosting and not name-based virtual hosting like it was possible in pure HTTP thanks to the host header.
The solution was found with a TLS extension, the Server Name Indication (SNI), something that the client sends early to the server and gives the website name, so that the server can send the appropriate certificate, and hence we are back in business in the name-based case where you can theoretically have an infinite number of names resolving to the same IP for them to be served by one given webserver.
In this moment, I am learning how the DNS and domains resolutions work and I have a question.
Let's take a.test.com for example.
As I understand it, first of all, the intermediary ISP DNS server is called. If it has the domain IP in cache, it returns it. Otherwise, it does consecutively these following tasks :
It calls a root DNS server which returns a com DNS server IP
It calls that top level DNS server which returns the test.com DNS server IP
It calls that DNS server to finally get a.test.com's IP
Is it correct ?
And now what does it happen when we resolve a.b.c.test.com ?
Does it call another DNS server or does the c.test.com's DNS server contain the a.b.c.test.com's IP ?
Thanks
Yes, you are pretty much correct. Nothing different will happen in next steps: c.test.com will respond with a referral to more authoritative server (the one for b.c.test.com), or if itself is authoritative then it will respond with an answer.
My Oracle 11.2 database schema has a scheduled job that queries a webpage on my website every few minutes. The database and web servers are two physical Linux machines that sit next to each other and have local IP addresses 192.168.0.11 (database) and 192.168.0.12 (web server). There is a RJ-45 cable cross-connect that directly links the two servers on the same subnet.
If I enter the web address http://xxx.xxx.xxx.xxx/path/to/webpage where xxx.xxx.xxx.xxx is the external IP address, things work fine. Things also work well if I replace xxx.xxx.xxx.xxx with www.mydomain.com.
However, I'm thinking it should be much more efficient if I could re-write xxx.xxx.xxx.xxx as 192.168.0.12 thinking that this would avoid having the request go out on the internet and come back, but rather stay on the same subnet to get to the webpage (thus saving time and resources).
req := UTL_HTTP.BEGIN_REQUEST('http://192.168.0.12/path/to/webpage');
When I try that, I get a 404 error, which makes me think it didn't get to the right webpage.
Can I keep the query on the same subnet by modifying the hosts file or some other way?
My current hosts file already contains an alias for the email server, that is:
192.168.0.12 mail.mydomain.com
If I also include the web address such as
192.168.0.12 mail.mydomain.com www.mydomain.com
would that keep the database on the same subnet when accessing the website? Or will it still leave the subnet to get there? Also, will it confuse things now that I've got two aliases (e.g. one for the database to send emails and one for the database to access webpages)?
I am not sure I would add "192.169.0.12 mail.mydomain.com www.mydomain.com" if that is not the proper IP for the host. That might only make things more confusing.
Assuming that you can ping 192.168.0.12 from the DB server, make sure that your Web Server is listening on the 192.168.0.12 address as well. It could be listening only on the external IP address, in which case, it will return HTTP 404 to every request on the 192.168.0.12 IP/interface.
On Apache, the httpd.conf file would have
listen xxx.xxx.xxx.xxx:80
which would make it listen on the external IP only.
Please note that if the purpose of your HTTP requests is to test the web server availability, you may be better of leaving things as they are. The external test is much more compreheensive than a local one could ever be.
Reading a lot about servers, load balancing and similar topics, a question came to mind.
DNS servers are servers which gives you the IP for a given domain name. Is there a "dictator" knowing all the valid DNS servers in the world? If I want to make a DNS server, and someone requests a website it doesn't have. How would it know which other DNS to redirect the request to? What if I tell facebook.com to have a spoof IP, and everyone getting the IP from my DNS server would be communicating with a spoof facebook server? Obviously, this isn't how it works (at least not at a big degree), because then someone would have done it already to attack hundreds of people.
When one registers a domain, one has to specify the name server for that domain. What happens during this process? Is a request sent to this DNS server to notify it there is a new domain to save in the database? If so, how can anyone own the top domains like .com? And why cannot I for example make my own top domain name if I can make my own DNS server?
After looking at nginx as a load balancing system, I'm starting to wonder a bit. Is it so that a request to http://www.google.com/ works like this? The computer asks a DNS server for the IP address for google.com, and then requests it? This will only be one IP, and all requests to Google ends up at this one server? And then this IP will be connected to a nginx server, or a more basic hardware unit to route the request internally to other servers? So all requests go to one server before it redirects the request to a data center?
After looking up google.com, it says the name servers are ns1.google.com etc.. But what is the point of them, if you need a different name server to get to ns1.google.com in the first place?
Obviously what I've written doesn't make sense, because if it were true, the web as a whole would be unusable because of people exploiting the possibilities for malicious causes. And I can't imagine how ONE server could handle ALL the requests thrown at google.com.
I've tried searching Google, but all I get is theoretical explanations that led me to where I am now. It would have been great if someone would point me to some articles that explain this thoroughly, and hopefully a lot of other people will find this question useful.
Anyone can run a DNS server, but the challenge is getting someone to use it. Normally the DNS server IP is provided as a DHCP option or is statically assigned. If you can get someone to use your server, you can return any IP for any hostname, including creating new top-level domains (subject to any filtering at the client, of course. Web browsers might have difficulty with a new TLD, for example). Note that with DNSSEC, this will eventually change, as the name record will be digitally signed and your server won't be able to fake the signature exactly.
DNS servers operate in a tree. When one server receives a request for a domain it does not control, it forwards the request on to another DNS server. The other DNS server may be the one which returns the IP (this is called the authoritative server), or it may return a NS record which points to another server which then must be queried. The DNS root servers provide for resolving TLDs.
A DNS server does not need to always return the same IP for a given name. It may choose to return a different IP based on region, client IP, or even per-request. This is the most typical way to load balance. Multiple DNS servers can also load balance the DNS requests by using anycast routing, where many servers share the same public IP and traffic is routed to them randomly by publishing multiple routes for the same IP.