I have a sub-domain sub1.primary.com that works correctly. Now I need to setup sub2.primary.com and have it point to the same web application as sub1.primary.com. I tried it as a new A record and a new CName however when I try navigating to sub2.primary.com and expect to see sub1.primary.com I see a completely different application that sits on sub7.primary.com.
I have tried the A record solo, the CName solo, both together, and each instance with and without pointer records. I am using a Windows 2003 Server with IIS 6. I tried googling for an answer and couldn't find any information.
Here is my setup at the moment. I have created a Host (A) record in DNS for sub2.primary.com with an associated pointer record. I have added the sub2.primary.com to host headers of sub1.primary.com. Whenever I navigate to sub2.primary.com it displays sub7.primary.com instead of sub1.primary.com. Which is bizarre because if it were going to default to something I would rather it default to www.primary. com.
I don't know if it matters but the sub1.primary.com is under SSL and so is sub7.primary.com, along with 5 others on a *.primary.com SSL cert.
Each subdomain should have an A record pointing to the same IP. I sounds like this is what you tried first -- if that didn't work, I'd suggest making sure that your web server's vhost configuration is sending sub2.primary.com to the right place.
When IIS hosts multiple websites on the same IP address, it uses the incoming request URLs to guess which virtual site to send the client to.
In other words: you need to configure your host headers to accept both names for the appropriate web site. Microsoft publishes some good how-to documentation here and here, or here is a more detailed explanation.
Related
To preface this, I am new to backend web development so I'm coming at this totally clueless. My past experience is with Netlify, which makes it pretty seamless to add a custom domain to a website with their free DNS service.
To start, I am working on a Flask application that ideally I would like to put on a subdomain of my website (i.e. app.my-website.whatever, not actually my real domain since it includes my real name) on a different host, in this case Heroku, while keeping my main website (www.my-website.whatever) on Netlify. This required me to switch from using Netlify's DNS to using the DNS tools provided by Google Domains.
After deploying the app on the free domain, which went just fine, I tried setting up my domain for the website, following these steps:
On my website's dashboard, I went to Settings > Domains > Add domain and under domain entered app.my-website.whatever, including the subdomain of course.
Copied the DNS Target Heroku gave me.
At my dashboard for my-website.whatever at domains.google.com, under DNS > Default name servers > Resource records, I added a custom record with the hostname app.my-website.whatever (Google Domains automatically adds the .my-website.whatever), type CNAME, TTL 600, and in the Data field I pasted the DNS Target.
In my Ubuntu (WSL) terminal, when I type host app.my-website.whatever, the output says app.my-website.whatever is an alias for {bunch-of-random-characters}.herokudns.com.
Unfortunately, this has not been successful. When I try to visit the domain, I usually get an error such as DNS_PROBE_FINISHED_NXDOMAIN or alternatively ERR_SSL_UNRECOGNIZED_NAME_ALERT. I've also tried the same thing with just www.my-website.whatever, and the same issues occur.
When I try to visit the site, most browsers will automatically append https://, which I would assume doesn't quite work since I do not have a cert set-up for my site, which I need to do manually.
Does the above error mean that there is a problem related to SSL, or is it something else? Is it because my browser forces https:// that I cannot see anything changing (i.e. would http:// work?)?
From what I can tell, I should be able to do all of this on the free-tire, but I have some confusion about a few details, and feel like I could be missing some other things:
Do I need a certificate/SSL for my custom domain to work at all with Heroku?
If it could possibly be an easier solution: Is there a better alternative to Heroku in my case?
With regards to setting up the cert, I tried following the tutorial here:
https://medium.com/#bantic/free-tls-with-letsencrypt-and-heroku-in-5-minutes-807361cca5d3
For certbot, as the tutorial explains, you are given two strings like so: <long-string>.<other-long-string>, and you need to serve a file at /.well-known/acme-challenge/ with the name <long-string> (no extension), but as an unrelated issue, I cannot get Flask to serve this file, even on a local dev server, and I just get a 404 message, which the certbot utility also reports. I can create another file, such as a simple .txt file, in that same directory, and it will serve just fine.
I'll admit, these issues feel a bit basic, but I genuinely am lost, and none of the guides or posts I see online seem to have any remedy or explanation for what is happening here.
If there is any more information I should share, please let me know.
I have developed an app and make it available via Heroku. Now I would like to add a custom domain name via Ionos however I don't know how to configure it. When using EC2 instances I would configure an static ip address but for Heroku, I don't know what to do. I have checked other post about this but none a precise or recent about what to do.
Thanks for you attention and have a Great day.
Had the exact same issue and here's how I made it work (just specifying I'm not an expert, so take this answer with a grain of salt):
First you'd have to go to Heroku in your app setting and then add the domain name you bought. It's important that you write the host when adding it, like put either www. or *. at the beginning of the domain. It will give you back a DNS target which you will then need to use on Ionos.
Secondly, you'd have to bind this DNS target on Ionos using a CNAME. Just go to your domains, click the one in your list, then open DNS and click Add a record. Choose CNAME and then put www as provider and past the DNS target you copied in target field. Finally, confirm the changes
Wait a few seconds/minutes, navigate to www.yourdomain.whatever and tada!
About static IP address, Heroku made some docs, and that won't work, you'd have to use dynamic ones. So in a nutshell, use CNAMEs instead of A records
Here are some docs if you want to dig more into this
I'm trying to do something pretty simple. I have a domain on godaddy. I want to use Azure Dns to host the domain and connect it to an azure website.
I have it working for www.mydomain.com with the CNAME approach. However I cannot get the root domain, i.e. my domain.com to work with this approach. I tried adding an * A record but that didn't work. I also tried to do CNAME with # but that didn't work either.
Does anyone know how to get the root domain to work? This seems pretty basic but there is no documentation and it is not obvious.
Thanks
Thanks for feedback on this one!
If you need to create the isolated deployment with the static IP, take a look at the Service Environment. The reference first and second.
As you mentioned Azure DNS, i assume that you refer to the Azure DNS service. If so, then it is possible if you have the needed access. Reference for the DNS zones.
Regarding your question about www and CNAME, there are some nuances that should be taken into account and set up. Please refer to that post.
You can set up a DNS 'A' record in Azure DNS to point to the IP address listed for the site in the Web Apps portal (as per the screenshot provided by an earlier answer). The Web Apps team provide the IP address for precisely this purpose, and they know that they can't change these IP addresses because DNS entries would break.
Note that there's no need to use a wildcard record (name = '*'). You should instead use an A record at the domain apex (name = '#', or if using the Azure Portal you can also leave the name blank).
If your hosted your WebAPP in free website plan didn't have any option for adding * A record. You have to Change your web App plan to at least Shared Plan instead of free Plan.
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/
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.