In the old days (the early 90s and before), one computer could host one domain. As you rightly guess, that was a waste of resources as computers became more powerful. So "virtual" hosting was the answer to that, known as "vhost".
How standard vhosts works
Each vhost has an account within a standardized user folder, and you could run as many vhosts on a computer as you needed. If you dig around a standard RHEL-type Linux install, you notice everything is in the
/home folder, with subfolders for each account, which corresponds to a single domain. Any time you create a new domain, you generally make it a folder under home. The folder is usually either named after the domain or the vhost user (
/home/domain.com or
/home/myuser) -- and then all of the subsequent folders are underneath it, with both public and non-public domain/site data (i.e.,
/home/domain.com/public_html)
-- Plesk uses it's own
/var/www folder instead of
/home.
-- The same is true for Windows IIS, and the standard
X:\Inetpub\ structure
-- Debian/Ubuntu vary a bit from the exact structure found in RHEL, but it's the same basic concept.
How cPanel vhosts works
cPanel does more of a voodoo workaround, using subdomains mixed with vhosting. It's not "true" vhosting, as far as I'm concerned. A cPanel account only gets access to one true vhost/user folder in Linux, but still allows the user to create multiple domains. The problem is that this setup opens up the potential for duplicate content, if it's not setup properly by both the host and the user.
cPanel users the "add-on domain" method:
| You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community. |
Consider three domains from a single account:
(1) myportfolio.com,
(2) myblog.com,
(3) myjokes.com
One is the main account's domain, and the other two are therefore add-on domains. Let's say I originally bought the web space to host my portfolio and resume, because I'm looking for a new job. Later on, I decide to add a blog, to share my rants and observations in life. And then let's say my Facebook feed gets so many likes and laughs that I decide to start my own joke site, which has everything from clean to crude jokes.
cPanel's structure looks like this:
- /home/myuser/myportfolio.com/public_html/
- /home/myuser/myportfolio.com/public_html/myblog.com/
- /home/myuser/myportfolio.com/public_html/myjokes.com/
And the DNS looks like this:
- myportfolio.com
- myblog.myportfolio.com
- myjokes.myportfolio.com
- www.myportfolio.com
- www.myblog.myportfolio.com
- www.myjokes.myportfolio.com
Yes, that means you can access add-on sites from the main domains !!! 
Google may show blonde jokes at the same domain as your professional portfolio. Your blog entries about politics or religion will be associated to your portfolio. That funny photo on your joke site will show up in a Google image search of your portfolio domain. You have to write .htaccess in order to block/separate the sites -- and from day one, if you don't want bleed-through of content to show up in search engines.
How to avoid domain crosstalk in cPanel add-on domains
The solution is to use a dummy domain. 
Instead of making myportfolio.com the main domain, use a domain you own -- but don't use. For example, if your name is John Smith, and your portfolio is johnsmith.com, also register johnsmith.us and use it as the dummy. Just own the domain -- don't set up any nameservers at the registrar. Just buy it and squat it. (Consider it brand protection, if nothing else.)
With a dummy domain (mydummy.com), cPanel's structure looks like this:
- /home/myuser/mydummy.com/public_html/
- /home/myuser/mydummy.com/public_html/myportfolio.com/
- /home/myuser/mydummy.com/public_html/myblog.com/
- /home/myuser/mydummy.com/public_html/myjokes.com/
And the DNS looks like this:
- mydummy.com
- myportfolio.mydummy.com
- myblog.mydummy.com
- myjokes.mydummy.com
- www.mydummy.com
- www.myportfolio.mydummy.com
- www.myblog.mydummy.com
- www.myjokes.mydummy.com
Since the main account does not connect, nothing will ever be shared between the accounts. Any attempts to connect to the DNS will results in an error to the lookup (which doesn't matter -- sometimes errors are fine).
There's also no rule that you must own the domain. You can use a domain that doesn't exist, if the shared host allows it. It's just safer to own the domain, in the unlikely event that somebody buys the fake/dummy domain. In the past, I've used owned dummy domains at
Stablehost,
Stream101,
SpeedySparrow,
Ninjalion,
Crocweb and
Semoweb. In each case, after sign-up, I simply informed the host of my dislike for the cPanel vhosts implementation, and listed out the domains I would be adding on once the account was set up. If it's your own VPS or dedicated server, then there's no host to disallow it, and you can do what you want.
Any flaws in this method ?
There is one minor flaw in using dummy domains, but it's easily sidestepped. When you enable or disable
Email Authentication in cPanel, the dummy DNS records cause an error. And it's not so much an "error" as much as cPanel is just confused.
| You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community. |
You'll end up with this error after you enable DomainKeys and SPF records for the first time:
Quote:
Status: Enabled, WARNING: DomainKeys cannot be used because this server is not a DNS server for mydummy.com [?]
Status: Enabled, WARNING: DomainKeys cannot be used because this server is not a DNS server for mydummy.com [?]
|
Pay close attention the URL of the enable and disable options. For example:
- Enable DomainKey: http://cpanel.host.com:2082/frontend/x3/mail/set_domain_keys.html?faction=install
- Disable DomainKey: http://cpanel.host.com:2082/frontend/x3/mail/set_domain_keys.html?faction=uninstall
- Enable/Disable SPF: http://cpanel.host.com:2082/frontend/x3/mail/set_spf.html
Note that the exact URL will vary from host to host. Pay attention. It's the end of the URL that matters most.
If you add a domain, after SPF and DomainKeys records are already "installed" (added to mail and DNS records), then you'll need to quickly disable/enable to catch the domains, and add authentication. That's just how the cPanel GUI functions. When using a dummy domain, however, it's often not possible to click the Disable/Enable buttons. You'll instead need to manually enter the URL into your web browser.
| You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community. |
That's easy enough to do.
What you do not want to do, however, is not use SPF or DomainKeys/DKIM. Those records are what help to ensure your emails end up in a person's inbox, and not their spam folder -- especially when it concerns free and popular mail services like GMail, Hotmail, and Yahoo. With those records missing, free mail providers will generally divert your mail into the person's Junk/Spam folder -- and that's not good for you.
I hope this has been helpful and educational. 
__________________
Need a good host? Find one here --
List of the Best Web Hosts in 2012 - Shared, reseller and VPS hosting
