Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I've noticed that a lot of websites redirect you from the unqualified domain to the www. subdomain. Is that the best practice as far as webapps go?
But not everyone does it. For example, heroku.com redirects you to www.heroku.com, but stackoverflow.com does the opposite, redirecting you from www.stackoverflow.com to stackoverflow.com.
What's the best practice here, if there is one, and why?
The web right now is leaning towards not using the 'www'. However, you should always make sure (right now anyway) that both www.domainname.com goes to the same place as domainname.com.
As for which you set as the main server name, and which is the alias, thats kind of up to you, or maybe even your target market.
You can get either to work and they both should be setup to function.
There is one difference in the DNS handling of them. A subdomain www can be re-routed with a CNAME record to another hostname, which many CDNs require (e.g. Akamai) so sites on Akamai could not use the raw top-level-domain as their final URL. A straight top-level-domain (e.g. example.com) is routed to an IP only (for A and AAAA records).
If you're just directing to your own server though without getting fancy about hostnames it doesn't make any difference, but if you're going to get into working with CDNs, it probably will make a difference.
My mom always puts "www" on the front of everything. So if I tell her "https colon slash slash secure dot example dot com", she'll likely just hit http://www.example.com/, or if I'm lucky, https://www.secure.example.com/. The world is mired in tradition. As SilicaGel said, you really need to support both.
Of course, from a technical standpoint, it matters not in the least ... except that the unqualified domain SHOULD also have some other services running on it, like SMTP (in case MX hosts can't be determined). Note that what SHOULD happen is often not what actually happens. Far too many people fail to follow standards.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
Not sure how to word the title.
I am in this situation...
I have had a website for a long time now where the domain name and hosting are managed by OVH. A few years ago, I setup the email service through Protonmail with a custom domain. To do this, I changed some things in the DNS Zone so that emails will be routed through Protonmail. I would have to go back and look at exactly what needed changed...
Now however, I am becoming unhappy with the hosting provided by OVH, so I would like to try out another host. The issue is that to switch hosts, I could either
Transfer the domain to another provider, and then setup the email from scratch.
Switch the nameservers at OVH to point to hosting somewhere else (e.g. A2Hosting).
I would prefer to take the second option, since this would allow me to try out a different host without having to reconfigure my email. If I like the host, then I would probably move everything over to them. But I simply don't know if it is feasible. So is this possible? And if so, how would I do it?
I am worried that if I just switch the nameservers at the host, then my email would be offline.
You are right, if you change the name servers you will not be able to receive mails (unless you configure the MX records at the new provider). In you case you can simply create 2 A records pointing the root domain (example.com) and * (which is for all subdomains, that don't have their own records, so www.example.com and something.example.com will work, as long as there are no other records for them).
For more information about the records configuration you better ask your new host.
And when you are happy with the new hosting you can change the name servers or transfer the domain or do whatever you want. Note that the web host, the domain registrar and the DNS host may be from different providers, it's not a must to have all the services at one place.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm running a website that uses an SSH certificate. This leaves for potential CNames:
https: //example.com
https: //www.example.com
http: //example.com
http: //www.example.com
From an SEO perspective I understand that it's best to choose one and then set up 301 redirects.
Within Google Webmaster tools one may choose www. and non www. versions. I arbitrarily chose the non www. version. No particular reason.
I then came on this forum for some code on how to edit my htaccess file to redirect all URLs to http://example.com.
I wondered if there was a best practice here. Does choosing a non https version nullify the SSH? From a search perspective are either of the 4 versions better from an SEO standpoint?
Anyone have any experience of thoughts on which of the 4 to choose?
I presume that when you say “SSH” (Secure Shell), you mean “SSL” (Secure Sockets Layer).
“http:” means normal unencrypted insecure http. “https:” means http layered on top of SSL/TLS, which provides encryption and authentication of the website. So yes, using the non-https version means you don't get the security benefits of SSL.
SSL certificates are usually only valid for a single specific hostname. e.g. if your webserver has a certificate valid only for www.example.com, but someone tries to access https://example.com, they will get either an error message or a scary warning. A CNAME is not enough: you need a valid certificate for that name as well. So use the name specified in your certificate. (If, of course, you have paid extra for a certificate that is valid for both example.com and www.example.com, then you may choose between them. But as I probably know less than you about SEO I shall not advise which one is best.)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Should my site be a www or non-www address? This is a pretty basic question. I wanted to see what people consider to be the best practice here. The reason I have to pick is I need to buy an SSL certificate for one or the other. Of course I can redirect to the one I pick on the back-end and the technicals are not a problem, but are there any opinions on which to pick and why?
Id answer both? Some sellers will offer both as standard. I believe Go Daddy offer the service help topic below.
http://help.godaddy.com/topic/234/article/850
The host name is essentially a convenience for your users to remember the name. From this point of view, it's mainly a marketing decision. If you've promoted example.com use that, if you've promoted www.example.com use that.
Redirections on the back-end as you seem to suggest don't sound like a good idea. The point of the certificate is to let your user be able to verify the identity of your server. If you only have example.com and if they try www.example.com over HTTPS, they'll first get a warning about an invalid certificate (thus they shouldn't follow the redirection).
You may be able to get both. Some CAs issue certificates that have SANs for example.com and www.example.com (sometimes for the same price or a little bit more, I think).
My vote is for the shorter one. Comparing your question to writing for the web, and writing in general - strive for maximum salience in the fewest words possible. 4 saved bytes can come in handy with 3rd party services like Twitter.
SSL certs support multiple names and also support wildcard pattern matching. I would add 2 names to the cert; you don't need to choose just one.
Consider adding the two patterns site.com and *.site.com to cover you, if you need to use an additional hostname / subdomain in the future.
Please note that both are needed if you wish to access the server as site.com, as the name site.com does not match the pattern *.site.com
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have a client app that faces the internet, but only clients will access. The site should never be indexed or crawled or viewed outside of our clients. We always concerned about DDOS and attempts to gain access. If the system can add one more level of being hidden, or harder to find, I don't see the negatives.
Users will never have to enter the domain name (think kiosks), and admins can use bookmarks. Yes, security by obscurity is no solution and never relied upon. But if you can add it to an existing and robust secured system, why not?
Is there any downside to having a random domain name like j398sh3-3nj23j.com?
I would love to hear some thoughts and opinions.
If you're never using where anyone will see it (even by rDNS on an incoming connection from your server), then the only real drawback is that you're paying for it when you could as easily use a random subdomain under a domain you already control (e.g. j398sh3-3nj23j.example.com).
But it'll provide zero protection from DDOS or attempts to gain access, as anyone who is in a position to extract a normal domain name from your client app will probably be able to extract this random domain name just as easily, and they may not even bother with domain names and just get the IP address your client is connecting to anyway.
Emphatically speaking, that's useless. As was pointed out above, using some subdomain of your own would cost less, be saner, and have more utility.
If you have a number of nodes on a private network that is not physically private, use a good VPN system and machine authentication with certificates. If you do that, nothing is accessible except the Internet-facing VPN software, and that can easily ignore anything that's not legitimate.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have quite a few domains that I manage (100+) and I'm getting tired of GoDaddy's management. Whenever I need to make changes shifting things around to DreamHost or Heroku to Google App Engine or my own VPS and private servers things eventually get hairy and it's tiresome to have to go to multiple locations in order to manage things.
I was curious if there was a solid option for developers that need robust domain management. I don't really (and PLEASE correct me if I'm wrong) see an answer with DynDNS or EasyDNS options. Perhaps I'm overlooking something.
I'm really looking for a single console to rule them all (i.e., register wherever and set NS entries to the master service) and to then be able to go into a domain and, by using a template split everything out to where I want it go go. In other words by setting up my own DNS templates I could with one fell swoop set up Google Apps sub domains, development dyndns cnames, AWS CDNs, etc. etc. etc.
Anyone aware of such a comprehensive solution?
I'm quite happy with DynDNS but I'm equally satisfied with Zerigo. Templates, AJAX interface, migration tools, an API...
Short of deploying your own infrastructure or piggybacking off something like Dynect, I'd hazard that Zerigo should do everything you want. The fact that it's recently been acquired by 8x8 suggests other people agree.
[I don't work for them if this sounds like a plug ;)]