I need to do a setup, where users would be able to access URL sub1.domain1.com that would be mapped by DSN to sub2.domain2.com, so all further communication would appear to be with sub1.domain1.com, however in reality it would just be "redirected" to sub2.domain2.com. HTTPS is required too, so simple CNAME wouldn't do it.
So far I have found out about SAN certificate. With that certificate it seems like it would be possible to accomplish this. However it has one drawback for me - with every new domain that is added to this certificate, all other domain owners must confirm this. And this is not very suitable for my case, because I expect new domains to be added on regular basis.
All domains would point to one certain subdomain (for example: sub1.domain1.com -> sub2.domain2.com,sub3.domain3.com ->sub2.domain2.com, sub4.domain4.com->sub2.domain2.com ..), so the certificate doesn't have to allow redirection between all domains mutually, but it would be enough to allow redirection from all domains to one certain domain (sub2.domain2.com)
Are there more suitable alternatives to accomplish this?
If, when user types https://sub4.domain4.com in their browser's address bar, you don't want (when the page is displayed) address in the bar to change to https://sub2.domain2.com then technically there is no HTTP redirection involved. You just have one website/webapp which is reachable via multiple hostnames (which is nothing unusual).
You need
CNAMEs to be in place
If you can't get (or it is complicated to maintain - which is expected, especially if you do not own the domains) one SSL/TLS cert with all hostnames, then you can always configure your webserver with multiple virtual hosts, each with their own certificate, and keep adding virtual hosts as needed. All virtual hosts can be configured to serve the same content (or just reverse proxy requests to the same one webapp running behind the proxy). Technical implementation depends on the platform used, but is typically not complicated.
Related
I purchased a domain name (we'll call it "exampledomain.com"). There is no website tied to the domain and there are no plans to do so.
I want to redirect all URL variants of this domain to an existing website I also own: (we'll call it "destinationdomain.com")
If a user types any of the following, I want to redirect them to https://www.destinationdomain.com/
https://exampledomain.com/
https://www.exampledomain.com/
http://exampledomain.com/
http://www.exampledomain.com/
How would I set this up?
What I believe I need to do is:
Add exampledomain.com as a Subject Alternative Name (SAN) to an existing SANs supported SSL I own for an existing website.
Point IPs of exampledomain.com to the IP used by destinationdomain.com
Add code to destinationdomain.com so that when it receives requests from the above exampledomain.com variants, it performs a 301 redirect to https://www.destimationdomain.com
POSSIBLE ALTERNATIVE?
Set up domain forwarding from exampledomain.com to https://www.destinationdomain.com/
Add exampledomain to destinationdomain.com's Subject Alternative Names (SANs)?
Is this accurate, or can I achieve this without step 3?
Thank you in advance.
Point IPs of exampledomain.com to the IP used by destinationdomain.com
You need to point it somewhere. It doesn't have to be the same server as you are using for your other site. (e.g. I might do this all in AWS and use an S3 bucket to do the redirect).
Add code to destinationdomain.com so that when it receives requests from the above exampledomain.com variants, it performs a 301 redirect to https://www.destimationdomain.com
The server that you point the new domain to does need to issue a 301 redirect.
This doesn't need to be anything to do with the old domain though. Even if they are hosted on the same server, you can use Virtual Name Hosting to use separate server configurations.
Add exampledomain.com as a Subject Alternative Name (SAN) to an existing SANs supported SSL I own for an existing website.
You will need the domain in the certificate for whatever server is hosting it. If you're using the same server then setting it up as a SAN makes sense.
If you look at the documentation for GitHub pages, it has a pretty strong reccommendation to use a www domain for your custom domain site hosted on GitHub Pages.
From here: https://help.github.com/en/articles/about-supported-custom-domains#www-subdomains
A www subdomain is the most commonly used type of subdomain, in which
the www stands for World Wide Web. For example, www.example.com is a
www subdomain because it contains the subdomain part www.
We strongly recommend that you use a www subdomain for these reasons:
It gives your GitHub Pages site the benefit of our Content Delivery Network.
It is more stable because it is not affected by changes to the IP addresses of GitHub's servers.
Pages will load significantly faster because Denial of Service attack protection can be implemented more efficiently.
Does this mean if I do not use a www domain I will not get the benefits of a CDN or DDOS Attack Protection?
What is the technical reason why there is a difference between a www and non-www domain here?
The difference lies in how you point the site to GitHub's servers in DNS.
The simplest use of DNS is to point a domain name, at whatever level, at an IP address, using an A record. The same address will be used by all users, and can be changed only by the owner of the "zone" where the A record was added - in this case you, configuring the zone of your custom domain.
A smarter way is to alias a particular domain name to a different zone - in this case one managed by GitHub - using a CNAME record. The owners of that zone can then change the IP address as needed, and can even give different answers to different users based on their location (which is where the CDN reference comes from).
The key restriction however is that you can't use a CNANE as the root of a zone. See this Server Fault question for the technical details.
If you own "example.com", you can point an A record for the root of that domain at one GitHub IP address (or a few, selected essentially at random by visitors), but will give GitHub more freedom to route the traffic if you point a CNAME for a sub-domain, like "www.example.com".
Some DNS providers offer tools to work around this limitation by adding a fake record for the root of the domain that looks like a CNAME, but may be labelled differently (e.g. ANAME, ALIAS). When asked for the root A record, the DNS provider looks up the actual A records for that domain and returns those. This is useful for records which change over time, but because the address is being looked up by your DNS provider not the actual visitor, it may still prevent GitHub serving the best address for that visitor.
DNS does not provide a reliable mechanism for forwarding on apex/root records (e.g. example.com) but does for subdomains (CNAME). In practice this means that while you can point an A record to a single IP address corresponding to a node on Github's infrastructure, they aren't able to route DNS lookups for your apex record to other IP addresses that are closer to the request (CDN) or use DNS to mitigate the effects of a (D)DoS attack.
Some DNS providers do offer synthetic records (ALIAS, ANAME) that mimic the behavior of a CNAME record with apex domains (e.g. dnsimple), but they're not widely available, introduce additional complexity and latency, and don't provide the same level of geographic routing opportunities to Github et al.
I have a couple of web apps in azure (same codebase, in different regions) that I need to set up as end points in Traffic Manager.
One of those sites is already Live. It is configured to support multiple domains, but all requests are 301 redirected to a specific domain, for SEO reasons. The other site needs to work in the same way of course, within the Traffic Manager setup.
The issue is that Traffic Manager needs to be able to ping the *.azurewebsites.net domain and receive a 200 response to work, but with the current redirect rule in place on the endpoints, this will not work.
If I remove the redirect rule then Traffic Manager will work, but it means that requests for the sites at *.azurewebsites.net will not be redirected (and so presents an SEO concern).
The solution I'm heading towards is serving up a different robots.txt file (with a Disallow: / rule) if the request is for the azurewebsites.net domain. Is this feasible? How might I go about doing this?
Are there any other ways I could make this work?
thanks
I'm going to rework the current redirect rule so that it doesn't redirect for one particular path on the azurewebsites.net domain (*.azurewebsites.net/favicon.ico), which should enable Traffic Manager to ping the site, whilst keeping SEO ok for the rest of the Urls.
7 years later and some months, the answer seems to be in the traffic manager's config under other expected codes, so you can add 301-302 to that list to make your host health show online.
I have a doman, mydomain.com as well as mydomain.biz and would like the the latter to be a synonym for the former: whenever a user enters www.mydomain.biz they are taken to www.mydomain.com.
I have everything working for mydomain.com and thought, from my limited understanding that a CNAME record would accomplish what I'm trying to do, so I have
NS mydomain.biz. = (nameservers that work fine)
SOA mydomain.biz. = (values that work fine)
CNAME *.mydomain.biz. = mydomain.com.
and when I host mydomain.biz I get
www.mydomain.biz is an alias for mydomain.com.
followed by other information that exactly matches what I get with host mydomain.com. Yet, any attempt to navigate to www.mydomain.biz fails.
I'm also perplexed by what I see when I look at propagation of my NS records. Checking for mydomain.biz gives the nameservers specified above, but checking for for www.mydomain.biz gives the values specified (elsewhere) for mydomain.com
Am I not going about this the right way? How should I configure my DNS records to direct all traffic from one domain to another.
DNS cannot redirect a request. Lets take an example on what CNAME does to clarify:
CNAME: domainA ==> domainB
What that would do is send requests for domainA to the same IP as domainB. However the URL will remain domainA (so it's not a redirect, a redirect would actually change the URL).
If you are okay with having the site load under two different domains, then a CNAME record will do the job. However you need to make sure that your server is configured to handle requests from both domainA and domainB. The way you do that is very different depending on your server environment. For example if you are using apache, your virtualhosts determine what domains are handled (you could set it up so any domain is accepted). If you are on shared hosting however, you will likely be restricted to the domain you signed up with. Adding more depends on your web host so you'd have to take it up with them.
If on the other hand you want the visitor to be redirected to domainB, you'd have to point domainA to a server that would return an HTTP redirect. It could be the same server, you just need to configure it to return the HTTP redirect if the request is for domainA.
My domain with hosting plan: testing.com
Other domains, but without hosting plan: test.com and test2.com
All of them buyed on same company, so NS records same.
Maybe DNS type A would help in this situation ?
In short, if someone try to use test.com or test2.com all users would be redirected to testing.com
I assume you talking about web-hosting. If your hosting plan is name-based virtualhosting (and that is what you probably have), The answer is: DNS is not enough.
You have two options:
Add multiple domain names to your hosting (most hostings will allow this either for free up to N domains, or for some additional fee or as part of more expensive plan).
Use URL forwarding (aka URL redirection) service, like this one (there are plenty other providers as well).
With both methods, you need appropriate DNS records in your domains, it can probably be handled by either - hosting for option 1, or URL forwarding provider for option 2. Basically you will need A records pointing either to your hosting, or URL forwarding webserver.