I recently purchased a domain name from znetindia. Now I don't have any Server Host, where I can place my Static HTML file, so I placed them in public folder of Dropbox.
Because of this I wish to point my newly brought up domain name to a long file path provided by dropbox public URL like:
http://dl.dropbox.com/u/2025503/servers/Experimental%20projects/letstartup.net/index.html
And I have following options in my domain name page from where I brought it:
DNS will only allow you to specify a different hostname or IP address for your domain name; you cannot use DNS to specify a different URL. (DNS is used for lookups for smtp, imap, ftp, sftp, ssh, telnet, imap, sip, dns, dhcp, irc, xmpp, nfs, cifs, etc. -- far more than just web browsing.)
Many registrars / hosting providers will run a web server on a host for you that can immediately issue an HTTP 301 response to an URL of your choosing. My registrar, Gandi, has placed these controls under a "web forwarding" heading. They will run a webserver that will respond to all requests for your domain with an appropriate HTTP redirect code to an URL of your choice.
I do not know if ZNetIndia provides a "web forwarding" option -- certainly none is visible in the screenshot you included, but that isn't a surprise, because managing DNS is different than managing web forwarding requests. If they don't provide web forwarding as an option, then you can certainly get a super-cheap webhost that can either perform redirects as you wish, or provide you directly with hosting.
Related
I am trying to build a new DNS, which will act as a proxy for certain domain names and uses a public DNS as upstream.
My understanding of DNS:
Client asks DNS (x.x.x.x) about example.com
DNS will look up inside its zones (or parent and root) and find example.com can be found at i.i.i.i
DNS will send i.i.i.i to the client.
Now, client asks the ip address of restricted.test and DNS server knows it is a restricted website, so instead of giving the direct ip to the website, it gives it's own proxy address p.p.p.p to the client.
Please correct me if I'm wrong till now, but when the client tries to connect to p.p.p.p how the proxy server knows which website the client wants to go in?
I really want to know how these work under the hood
Thanks in advance.
This mechanism you are asking about is the Proxy Auto-Configuration (PAC) file.
Read more about it here :
https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file
And here :
https://www.websense.com/content/support/library/web/v76/pac_file_best_practices/PAC_explained.aspx
Essentially in corporate networks, a PAC file is pushed out to every computer, and browser settings are also configured to enable the PAC file. But it can also be done manually. Just check your browser proxy settings to see the location of the PAC file it is pointed to.
I have an Azure web app up and running, using a custom domain purchased outside of Azure... and that all runs fine. So I have https://myappname.azurewebsites.net/ loading fine with my domain name URL https://www.myappname.com
I'm trying to upgrade the web app, though using Azure Traffic Manager. I've cloned the app a few times, each on its own app service plan, and I have the traffic manager all up and running fine. I can successfully hit different versions of my cloned website based on the traffic manager configuration profile... so no issues there.
The only issue is that I can only access the "traffic managed" version of my website via the standard azure URL -> myappname.trafficmanager.net.
All examples I've seen say all I really need to do now, is go into my DNS Management screen, and add domain forwarding, however, my online DNS management tool does not offer this option.
I can't really change my A record in the DNS management screen, because I don't know the IP address of myappname.trafficmanager.net
Every place I've tried to change the name of the current/working Azure URL (like in awverify text files, www cnames, etc.) does nothing. The DNS still points to the single instance which remains in the IP address od the DNS managers A record.
Also, since my live/single instance is linked to the domain name (along with the SSL binding), I can't add those properties to the clones, which makes sense....only one version can be live. However I could unbind that when I make the switch from the single instance web app to the traffic managed set of clones, but I fear I can only bind that to one of the clones. I can't seem to bind it to the myappname.trafficmanager.net version, which might cascade down to all of its endpoints. Is there a way to bind my domain name and SSL cert to more than one version of my web app?
Thanks!
Is there a way to bind my domain name and SSL cert to more than one
version of my web app?
I don't think you can do that unless you have two different domains or subdomains with each own SSL cert. Each web app hostname is unique globally and each SSL binding is attached with the web app domain name.
If you have a purchased domain and just keep the default xxx.azurewebsites.net as each hostname. Then you could configure the two Azure app serves as the endpoint of TM.
By default, Azure provided a wildcard cert for this domain *azurewebsites.net, so you can automatically access this hostname with HTTPS without any extra cert. Then use a CNAME record www in the domain domain.com in your DNS provider to point to the traffic manager hostname myappname.trafficmanager.net. Since Traffic Manager works as DNS level, it does not validate the server and client SSL, you could safely ignore the SSL warning when accessing with traffic manager hostname.
Feel free to let me know if you have any question.
DNS A-records require that an IP address be hard-coded into your application’s DNS configuration
...which Heroku recommends avoiding. Heroku suggests two workarounds:
...using a DNS provider that supports CNAME-like functionality at the apex, and using subdomain redirection`.
My question revolves around the latter option (because the former isn't supported by DreamHost AFAIK):
Is it possible to redirect from the root (i.e. apex or 'naked') domain to the 'www' subdomain for HTTPS requests without the browser throwing up?
Heroku thinks not:
...applications requiring SSL encryption should use the ALIAS/ANAME configuration on the root domain. Subdomain redirection will cause a browser error when the root domain is requested over SSL (i.e. https://example.com).
...but I'm hoping that's an incomplete (or incorrect) statement.
CLARIFICATION UPDATE:
The real issue with redirecting from apex to 'www' is that typing https://example.com directly into a browser will raise a certificate warning. Sure, it's an edge case, but not a small one.
SOLUTION UPDATE:
I solved this problem with DNSimple. (Didn't even have to transfer my domain!)
I believe that easyDNS offers a similar feature, but surprised to find that most other domain hosting companies don't.
There are two separate but interdependent levels of indirection to consider here. The first is what IP address a DNS name ultimately resolves to. The second is what the server on that IP address does.
Remember that when you type a URL into a browser, the first thing that happens is a DNS lookup. Usually, that's handled by the operating system – not the browser itself.
So your browser will ask the OS, "what is the address of example.com?" The OS will look up the record, and if it gets a CNAME, will look up that record, until it finds an A record. The OS then responds to the browser with an answer.
Your browser then opens a TCP connection to that IP address:
If a http:// URL, it connects to port 80, then issues a HTTP request.
If a https:// URL, it connects to port 443, establishes a TLS/SSL connection (which means validating certificates), then issues a HTTP request over the secure channel.
Only at this point can HTTP redirection happen. The browser sends a request (GET /, and the server can respond with a 301 to any other URL.
Understand that "subdomain redirection" services offered by registrars are nothing more than a regular HTTP server that issues 301s. When you opt for a registrar's redirection option, they just set the A record of your domain's apex to a server they control, and that server tells browsers to go to www.example.com.
Since most registrars don't allow you upload a SSL certificate to their redirection server, browsers cannot establish the necessary secure connection to the server, and therefore they never issue a HTTP request. Thus, requests for https://example.com fail.
So why can't you just CNAME the apex? It is forbidden.
The domain system provides such a feature using the canonical name
(CNAME) RR [Record Resource]. A CNAME RR identifies its owner name as an alias, and
specifies the corresponding canonical name in the RDATA section of the
RR. If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different. This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.
The spec requires that a CNAME record be the only record for a given (sub)domain. This is at odds with the requirement of having a SOA record on the apex. (There are some efforts out there to change the specs to allow CNAME and SOA to coexist, but there are still many broken SMTP implementations that will be confused by the CNAME on a domain.)
You have the following options to get SSL working on the apex:
Use a third-party service that supports SSL on the redirect server. You'll likely pay for this. Here's one service. I would not recommend this route, since it takes the control of reliability out of your hands, and requires you to hand over the keys to your SSL certificate to someone who may or may not be trustworthy.
Run your own redirection server. Since the apex requires an A record, you'll need a static IP, which services like Heroku and AWS' ELB do not provide. So if you're in a cloud environment, it will be very difficult (if not impossible) to guarantee reliability. On the plus side, you retain control of your SSL keys.
Use a DNS host that allows you to set an alias. Point the alias to your Heroku domain/ELB/whatever. This is most likely the best option.
An alias is not technically a type of DNS record. Instead, it is a special configuration on the DNS host side that returns an A record from the result of another lookup. In other words:
Your OS issues a DNS request for example.com to your DNS host.
Your DNS host reads the internal alias configuration, and issues a DNS request for that domain. So if you have an alias set up for example.herokuapp.com, it would look up the A record of that domain.
The DNS host returns a simple A record with the IP(s) it got from the alias lookup.
With an alias record, you could point your apex to the same cloud load balancer that your www domain is CNAMEd to. Assuming you've set up SSL on the www domain, the naked domain will work just fine. At this point, it's your choice whether your app issues a redirect, or just serves your content directly over the naked domain.
You need a certificate that secures both www.example.com and example.com.
NOTE: I have not tried this with Heroku app.
I am still sharing this solution here as this is the first stackoverflow page that shows up for 'redirection from naked domain to www version' search. It may help others who are looking for an answer to generic redirection.
I have successfully redirected naked domain to www version.
In addition, I also redirected the HTTP version to HTTPS version using google domains DNS settings in synthetic records.
Delete any 'A' records for '#' in your DNS.
Add a synthetic record with subdomain = '#' and redirect it to www version of your website.
After addition, edit this same record and change the default 'http://www.example.com' to 'https://www.example.com' . Note the 's' in http here. Click Save.
That's it. Your redirection is now taken care of by DNS settings.
Detail steps are documented here:
https://www.am22tech.com/redirect-naked-domain-www-http-https-google-domains/
our hosting account is set up with the domain www.nashman.ca, and our application is at www.nashman.ca/hub. We have another domain that forwards to www.nashman.ca/hub and that's hub.mhn.co. The problem i'm having with this is that the forwarded domain adds on the /hub whenever you navigate to another page from hub.mhn.co, so the domain shows as hub.mhn.co/hub/admin when you're in the admin area, for example. I need the domain to stay consistent, and never show that folder name, because its breaking some of the javascript I use. What is the best way to set this up?
edit
I've been doing some reading about URL Rewriting, and looking into it - my hosting provider supports the IIS7 URL Rewrite module. All the tutorials I've found so far detail how to set up rules using the IIS config tools, but I don't have access to them. Is there a way to do it by editing my web.config in my apps root directory? And will this solve my issue?
Is the default page for hub.mhn.co using a redirect to www.nashman.ca? If so, what is happening is that the forwarding software basically returns a new URI that the browser requests, and the new URI will replace the old one in the browser window and thus in all future requests. You're probably redirecting to ~/hub/ (the hub subdirectory of the site root) which will result in the browser requesting a new URI that keeps the domain name but tacks on the subdirectory.
If you have direct control over the DNS and your webservers, you can use the DNS configuration to direct a request for the hub.mhn.co domain directly to the /hub subdirectory of your webserver. That way, the browser never knows that hub.mhn.co is actually www.nashman.ca/hub/. You might have to direct to an alternate port on the webserver and map that port to the subdirectory, depending on your DNS software (IIRC, most can deal with ipaddress/subdir routes, but some can only handle routing to ipaddress:port).
If your IT department does not have direct control/ownership over your DNS routing, or your exact hosting environment, you are more or less at the mercy of your hosting provider. They may be able to set up their environment to do the same thing, or not; all you can do is ask.
EDIT: Basically you have two options left if you're hosting remotely and can't use their DNS to reroute silently.
First option: clone (copy all files from) the web layer of nashman.ca/hub as hub.mhn.co under a different root space in your hosting environment (try to keep any hooks to service-layer code over at nashman so you don't have to copy the whole vertical slice). If you must also keep the UI under the /hub/ subdirectory, you're repeating code, but you may be able to mitigate this with deploy scripts that will allow you to deploy one local copy of your codebase to various locations. This may also cost more as your hosting environment is now hosting two non-trivial sites.
Second option: host the site and/or resolve the calls on your own hardware. As long as you have a public, static IP address through your ISP, you can provide a DNS server that will be the "authoritative" server for nashman.ca and hub.mhn.co domains. Your ISP or a third party domain name registry can provide a "pass-down" route to get requests from the TLD servers down to you. Then, you can route requests to whatever IP address, port and/or subfolder you like; that can be a remote webhosting provider (as long as they don't mind JUST hosting your site) or your own webservers. This will require the hardware, and a static IP from your ISP. If you lose power to this server, your site will be unreachable until power's restored. If the IP address of your DNS server changes, your site will be unaccessible by DNS until the server that routes requests to you updates its routing table with the new IP (which can be up to 24 hours).
I have a Default Web Site and another web application (let's call it Application2) inside the Default Web Site in IIS7.
I have 2 registered domain names, let's say www.example.com and www.example.net.
I would like to configure things that when I open www.example.com I get Default Web Site, when I open www.example.net I get Default Web Site/Application2.
www.example.com -> Default Web Site
www.example.net -> Default Web Site/Application2
How can I do that?
First you need to decide if your going to use Name Based or IP Based hosting.
IP-Based uses unique ip's to determine which virtual host it will serve and Name Based will actually use the host header which is sent by your client browser.
So let's see two scenarios:
Scenario # 1 (ONE IP TO SHARE)
You have a server with only one IP, could be either private or public as long as the domains you are serving are properly configured in the dns serving you internally or your client externally (NAT).
I suggest that for the sake of this tutorial you stop the default website. Ok.
You will set up one site in II7 and name it accordingly. Go to the right hand side of the manager and look for "Bindings" under actions menu; making sure you have the new site selected on your left pane. Now under "Site Bindings" select the ip address you will be sharing between the sites (name based hosting). Under "Hostname" enter domain # 1 "www.example.com", hit ok.
Follow the same procedure above with the other domain or domains, making sure they have diferent hostnames and same ip's.
That's it. You will now be able to start those sites and run them at the same time.
The same principle above applies if your using the "Default Site". "Default Site" is just a name MS gave the default created one.
Scenario # 2 (MULTIPLE IP TO SHARE)
If you have either some private or public ip to spare, or at least until you do the exercise the only diference here is that sites you will set up and don't have to specify the "Hostname" per each site, as this is basically done in the DNS zones itself. The sites will respond for any request made to those ip's on port 80 regardless.
When will you need to use multiple Ip's to serve websites. Well it all depends.
Some reasons are: Network Isolation (Security), Applications which don't work well under name based hosting, SSL Certificates Bindings 443(PRE II7), and mostly complete control over site. There are of course more reasons, but I'll let others write a bit also.
Have fun.
Edit... upon further investigation I found that if you can set up multiple sites and run them simultaneously. Just need to stop and start the sites after setting the host values to get them to both run at the same time.
Original post:
The straight-forward way to do this would be to add another application by opening IIS and right-clicking Sites then select Add Web Site. In there you can specify the physical path of Application2 and also set the "host" to "www.example.net" which will filter all those requests to your second site. Any requests that don't match "www.example.net" will still go to the default web site.
That approach will work fine on Windows Server using IIS, but on Vista's IIS7 it won't work since you can only have one site running at a time. To start the second site, you'd first have to stop Default Web Site.