Last year I had a little surprise in that Warcraft-Maps.com was listed as an attack site. Turned out that either Burst or ValueClick were running some not-so-nice ads and got the site flagged. It did eventually un-flag, but I wasn’t thrilled.

I always thought ValueClick was the problem. They’ve got a huge amount of ads running on their network, and they don’t seem as selective as Burst!. You can imagine my surprise a few minutes ago though, when Kaspersky did the little “violin” when I visited my site. Turned out Burst doesn’t behave so well after all.

-

Last month, I dumped ValueClick – I was only serving Burst! Media ads, and Google ads.

Well, time to say goodbye to Burst. It’s rather unfortunate that one of the “better” providers has gone downhill in this way.

-

The reason I originally ran CPM ads to begin with was because the bandwidth that Warcraft-Maps.com used was the big part in upgrading hosting packages over the last 3 years. It used more than all the other sites combined, and effectively cost the most to run.

If you’ve ever wondered why “download” sites bombard you with ads, popups, pop-unders, and everything else, it’s because that bandwidth isn’t free – it’s got to be paid for somehow. As much as I despise pop-unders, I’ll admit I did have them running on the Warcraft-Maps site for quite some time.

And yes, running pop-unders on one of my sites did leave me with a dirty feeling inside – I’m still recovering.

-

However, that’s all in the past now. I have to give a big thanks to HostGator actually. Their unlimited hosting has allowed me to throw all the bandwidth-intensive stuff on there at a cost of under $10/month. How unlimited is unlimited? Well, Brent from HostGator recently posted on WHT, mentioning that he regularly comes across accounts using over 5TB of bandwidth per month. I’m way under that.

In any case, Warcraft-Maps.com is now running only Adsense stuff, which has generally shown to be safe to viewers.

Goodbye Burst… and here I thought ValueClick was the problem. Turns out you both were.

After about a week of not receiving any messages through the contact form on one of them, I suddenly realized… “ya know… it’s been a while”. I tried sending myself a test message through the contact form, and never received it. Sending from another email account worked though. Strange…..

Before going any further it’s worth noting that I’m using Google Apps on the aforementioned site for mail (gmail for domains).

To narrow down the cause, I did a couple things. First, I came across a little script on the Joomla forums (thanks to “ChiefGoFor”). It basically tests the PHP mail function (which Joomla uses by default) and looks like this:

<?php
mail(“youremail@domain.com”, “Testing PHP mail”, “Email sent successfully”);
echo “script complete.”;
?>

I made a file called “testmail.php”, plunked that code in, changed the email address to a hotmail one that I own, and opened in in my web browser. It worked.

——

Next I tried changing the email address it sends to from within the Joomla site, again, pointing it to the hotmail one I tried above.

It worked!

Problem was obviously either Google not accepting messages from the server, or the server not sending to Google for some reason.

I popped open WHM, and ran the “Mail Troubleshooter” (under the “Email” section in WHM). When I typed in the address hosted through Google Apps, it spit out the following message:

virtual_aliases via virtual_aliases router forced address failure

Fun.

I tried entering a hotmail address, and it showed the proper MX lookups through Hotmail.

Now all the pieces were falling together.

——

Here’s what was happening….

• The DNS isn’t hosted on the web server in my case. It’s hosted elsewhere. It’s properly set up (MX records and all).
• The web server however doesn’t look at the DNS server for a site contained on the web server. After all, why would it spend the time to look itself up?
• In short, while MX records were properly set up on the DNS server, they also have to be set up on the web server if it ever sends mail to an email address that reflects a domain on the server which is hosted elsewhere.

I’ll draw a little picture to explain it a little better.

As you can see from my wonderful drawing, if your mail is hosted somewhere else, it won’t matter that your separately-hosted DNS server was set up correctly – you’ll still have to add the MX entries to the web server (otherwise it’ll just look at itself).

The good news is that for those who self-host their DNS, WHM/CPanel will pick up the MX entries when you add them to the zone file.

For everyone else, MX entries can be added easily in CPanel’s “MX Entry” section.

If your site is pretty basic, you probably don’t need them, and having them load every time just makes it that much more painful for your dial-up viewers. Heck, mootools.js alone is 74 kb !

So how do you get rid of mootools? It’s pretty simple code that you throw in your template’s HTML file. Hopefully, you know where the template is, but if not, you can find it one of two ways (you may want to back up first just in case!):

• Browse to (and edit) the /templates/your-template-name/index.php file (located in the directory your website is in); or,
• From within Joomla’s administrator panel, choose Extensions / Template Manager , then click on your template (probably the one with a star beside it), then choose “Edit HTML“.

Depending on how the permissions are set up on your server, one method may be easier than the other. Here’s the code you’re going to put in the template:

<?php
//remove mootools.js and caption.js
$headerstuff=$this->getHeadData();
reset($headerstuff['scripts']);
foreach($headerstuff['scripts'] as $key=>$value){
unset($headerstuff['scripts'][$key]);
}
$this->setHeadData($headerstuff);
?>

Note that this goes near the top, right AFTER this:

<?php
// Prevent direct access sans Joomla!:
defined( ‘_JEXEC’ ) or die( ‘Restricted access’ );
?>

So once you’re done, the first few lines are probably going to look something like this (the blue is the stuff you’re adding):

<?php
// Prevent direct access sans Joomla!:
defined( ‘_JEXEC’ ) or die( ‘Restricted access’ );
?>

<?php
//remove mootools.js and caption.js
$headerstuff=$this->getHeadData();
reset($headerstuff['scripts']);
foreach($headerstuff['scripts'] as $key=>$value){
unset($headerstuff['scripts'][$key]);
}
$this->setHeadData($headerstuff);
?>

<!DOCTYPE html PUBL……..

That’s it! Save, load up your website, make sure to hit refresh once (F5), and view the source – no more mootools or caption.js! Your website should load faster, and dial-up users can save their tears for another site.

——

A couple final things to note:

1. Some Joomla templates (usually just the really fancy ones) may need mootools.js to operate properly. Make sure to check your template’s functionality afterwards.
2. There are a few Joomla plugins/modules/components that require mootools as well. Many lightbox modules do for example, and you may find that many image/photo/video galleries do as well.

If you have any issues, just remove that bit of code from your template and you should be good to go again.

——

Finally, as much as I’d like to take credit for the above, credit goes to someone on the Joomla forums who posted it long ago (I don’t recall who it was, or who came up with it in the first place).

It’s a bit of PHP code that can be used to get an idea as to how fast the processor is on the machine your websites are hosted on – or at least the speed you have available to you. A thanks to “webpan” of the WHT forums for putting up the code he used for his LiquidWeb test.

Basically, you create a php file that looks like this:

<?php
$startTime = microtime(true);
for ($i=0;$i<500;$i++) {
$j++;
for ($k=0;$k<10000;$k++) {
$j++;}
}
$endTime = microtime(true);
$delta = $endTime – $startTime;

echo “total time: $delta seconds.\n”;

//phpinfo();
?>

Call it “test.php” or something, and put it somewhere on your webserver – then browse and run it. You could modify it to do some more stressful math, but don’t go crazy.

I tried it on 3 hosts, and here were my results:

time in seconds - lower is better

Each test was run at 3 different time periods during the day. To make things a little more readable the times for each run are only shown to 2 decimal points. The variance here is the sum of the deviations from the average of all 3 tests.

You’ll notice the following:

• WiredTree came out on top, and VPSLink wasn’t far behind. HostGator was the slowest.
• Each run was *very* similar. There was almost no variance, indicating that none of the host machines seem to suffer from high CPU loads at certain points of the day.

—

But what does it all mean, Basil? (obligatory Austin Powers quote)

Well, as far as processor-intensive PHP tasks go, the WiredTree and VPSLink VPS’s are likely to be quicker, and pump out the results faster. In all likelihood they’re simply using faster processors than HostGator. There could very well be other reasons that HostGator came behind, but the fact of the matter is that there’s more processor speed/power available to both VPS scripts.

—

Does this mean that HostGator’s slow/bad?

Not at all.

There are so many factors that come into play, that you can’t base a host decision on one type of test. HostGator’s got a lot of servers, and I can guarantee you they’re not all the same. The same probably holds true of the VPS providers. If someone gets a brand-spanking-new machine, it’ll be faster than the old machines. It’s a “luck of the draw” thing as far as which machine you’re put on.

You also have to consider that there are many other things that come into play when you’re looking at how long it takes for a page to load somewhere. There are many things that go into tuning a server. A server that’s strapped for RAM, a poorly tuned MySQL database, a server that’s always waiting on IO, a server connected to the network with a 10Mbps port that’s being maxed out, the server location, and the datacenter’s connectivity are just a few examples of things that can really affect how long it takes for a page to load on the viewer’s end.

—

The test subjects (aka “You Rigged the Test!”)

I’ll be the first to admit that these weren’t necessarily level playing fields. Here were the candidates:

HostGator
Shared hosting plan
Apache/FCGI/SuExec

VPSLink
Link-4 VPS – Xen
Apache/SuPHP/SuExec

WiredTree
1024 VPS – Virtuozzo
LiteSpeed/LSAPI/SuExec

The way it typically works for PHP speed is this:
DSO > FastCGI >SuPHP
Litespeed’s PHP server’s a little tough to put in there although most of the info out there seems to indicate it may be faster than all the above. I have no way of knowing whether the speed of the above test is affected much by the engine serving up the PHP, although I’d expect the effect to be marginal in a test like this.

I’ll start off by saying this was originally going to be primarily about the performance differences. However, after a few hours of testing, I found there’s not enough of a difference to be worth mentioning – neither was consistently better than the other. Performance-wise, for the most part it really boiled down to how close each test location was to the nearest respective edge server. This was relatively small-scale testing with a site that pulled about 12 images per page (and thus pulled 12 items from each CDN), but I concluded that neither’s going to make a lick of difference performance-wise… at least, not for the typical individual who’s looking at these two for solutions.

That said, time to take a look at the merits of each at a basic level:

Preface:
SimpleCDN was designed straight-up as a CDN, and meant to be simple (hence the name). CloudFront on the other hand is built upon the structure of the other Amazon services, and can be thought of as more of a “bolt-on”. In fact, CloudFront uses (and requires) the Amazon S3 service for hosting the files – CloudFront then pulls the files to the CDN from S3. These are very different approaches. SimpleCDN is generally simpler to use, and more powerful in the options it offers. That said, anyone already using Amazon S3 extensively will probably feel more at home with CloudFront.

Upload Buckets:
For those unfamiliar with the way these work, you basically upload the files you want on the CDN into what’s called a “bucket”. It’s a pretty simple concept – you basically end up with a new URL where those files are located – no different from linking to files on a separate server/website, except that these are now on a CDN and should be served closer to whichever users are requesting them. Both SimpleCDN and CloudFront can use them. For SimpleCDN you use your favorite FTP client to upload the files. For Amazon CloudFront, you put the files up on Amazon S3, and set it up to pull from there.

Mirror Buckets:
For those unfamiliar with these (also called “origin pull”), these are often easier to implement with dynamic websites – particularly those where static content you may want on the CDN (such as images) are often uploaded/added to the site. Both Wordpress and Drupal have plugins for these. All the content you want on the CDN stays on your server/website. Requests for those files are redirected to the CDN which “pulls” the file(s) from the server/website, and begins serving them through the CDN. SimpleCDN has support for this. CloudFront does not.

CNAME Support:
This is often more of a “vanity” feature than anything else. It allows you to use something like cache.mywebsite.com, images.mywebsite.com, static.mywebsite.com, cdn.mywebsite.com ….. you get the idea. You basically use a subdomain or domain that you own, and use a CNAME in your DNS settings to point it to the CDN. That way, viewers see your pretty, professional-looking name as the page loads instead of an ugly long url. To be frank, most viewers won’t see/notice the difference with content that’s loaded within the page (template images, css, etc). In any case, both SimpleCDN and CloudFront offer this. SimpleCDN charges a 1-time fee of $5 for each CNAME you set up, while Amazon includes them for free (but with a max of 10 per distribution). This is one area where Amazon really has the upper hand price-wise, particularly if you’re looking to add a lot of CNAMES.

Peering/Edge Locations:
Both have a comparable number of locations, and for the most part they’re in relatively similar geographical regions. Unless you have a *very* specific geographical target (a specific city for example), neither’s likely to come ahead in this respect (the similarities were reflected in performance testing I did).

Expires Header and gzip Encoding:
SimpleCDN wins in this area hands-down. There are currently 17 combinations, and what they enable (a certain expires length, gzip, or both for example) depends on what URL you use to access the bucket making it easy to mix/match between them. As far as Amazon’s side goes, from what I understand you can set expires headers through S3 which will be pulled to CloudFront, but you need particular software to do it. CloudFront won’t gzip content either. You can technically get around it by pre-gzipping the content and using the PHP on your site to determine whether to grab the gzip or non-gzip version of items depending on the browser’s capabilities, but really… you get the idea. It’s ugly. SimpleCDN is simple, easy, and just plain comes out ahead here.

Payment:
SimpleCDN is completely pay-as-you-go, and they currently start you off with a free $15. At under 4 cents per GB, you’re looking at close to 375GB of transfer before you use it all up (minus any storage). You can also use part of this free $15 for the $5 CNAMES if you’d like. Once you’ve used it up, you’ll have to add more if you want the CDN to remain accessible. The lowest amount you can add at a time is $50. Amazon on the other hand simply bills you each month for your usage. Which is better is a matter of perspective.

Minimum Monthly Fee/Cost:
Neither have monthly fees, minimums, or costs. You pay for what you use – that’s it.

Starting price per GB of transfer:
SimpleCDN charges 3.9 cents per GB, no matter where the traffic is coming from. This gets even cheaper if you hit the 100TB mark in any given month. CloudFront on the other hand is a fair bit more expensive. Amazon charges anywhere from 17-22 cents per GB (depending on the location the content’s pulled from) for the first 10TB, after which the price starts going down. SimpleCDN is clearly ahead here.

Storage cost per GB / month:
SimpleCDN charges 75 cents per GB of storage per month. Since the Amazon content is stored on their S3 service, it’s much cheaper – starting at 15 cents per GB per month. However, with Amazon you’re also hit with all the S3 rules – so you’re charged for both data-transfer (including each time CloudFront pulls the files from S3), as well as GET/PUT/COPY/etc requests. Amazon is still likely to come out ahead here (especially if you store many terrabytes of seldom-accessed content), but it’s worth doing the math to see.

Starting cost per 10,000 GET requests:
SimpleCDN doesn’t charge for these. Amazon does, and Cloudfront will charge a penny for every 10,000 GET requests. Calculate how many static contents are on your website page that you’d be serving from the CDN. Multiply it by the page views in a month and you’ll get a rough idea as to how much this will cost.

——

A few notes I couldn’t quite squeeze up there:

• If you use SimpleCDN and decide to use CNAME’s as well, be sure to type it in correctly when creating it! Most of SimpleCDN’s website is very easy/intuitive, but the CNAME part is one area that isn’t as clear until you *read* it.
• While you can use as many expires/gzip options and combinations as you want, note that each CNAME can only point to ONE of these combinations at a time.
• There’s a Firefox plugin called S3Fox which is one of the quickest/easiest ways to upload files to Amazon’s S3 (and then push to CloudFront). You do have to read the instructions though – otherwise you’ll be right-clicking for a while to figure things out.
• Setting expires headers can help to reduce your transfer costs – possibly by a substantial amount.
• SimpleCDN has changed their policies in the past – they used to charge a flat rate depending on the file-size, and then give unlimited transfer. Hopefully they’re out of the “growing/learning/testing” phase and are well-settled on the current policies and prices but be aware that it wasn’t that long ago that things changed – they could always change again (in other words, don’t go adding enough money to cover you for the next 5 years of traffic – things could change)

So which CDN comes out ahead? Definitely SimpleCDN. It’s easier to use, it’s more flexible/powerful, it’s less than 1/4 of the cost of CloudFront, you won’t go mad with a calculator trying to predict your costs, and the “Simple” part of the name is well-earned.

That said, Amazon CloudFront is still a viable option in certain cases. If you’re already familiar with (and like) the S3 service, adding CloudFront to your mix may be a no-brainer. It’s also likely to be a less-risky bet since SimpleCDN has already scrapped/revamped their entire pricing structure once (much to the dismay of many), whereas Amazon’s been a relatively stable company for years. Amazon also has many strengths as a storage option. Finally, if you’re looking for a lot of CNAME’s and aren’t as concerned about expires headers and gzip (or are willing to go to the lengths to manually work them out), Amazon does give them out for free.

I used to use non-SEF url’s on a Joomla site, and recently turned on Joomla’s built-in SEF. Problem is that the old URL’s still “work”. Of course, this is great for people who visit – not so great when GoogleBot comes along.

GoogleBot comes happily along and for any given article sees the original archaic url with a bunch of parameters that have been there forever. Of course, there’s little incentive for it to use the “cleaner” versions. As far as it’s concerned, the archaic stuff is the original, and the new url’s are duplicate content. It could eventually change it’s mind as to the “preferred” page on it’s own, but there are a few fighting factors here. On one hand, the sitemap points to the “new” one, and it’s predominantly linked to through the current site. On the other hand, anyone who’s linked to the site in the past has linked to the “old” one, and let’s face it – it was there first.

To make the change and get Google looking at the right page, we’ll go over the things I tried that didn’t work, and then the thing I tried that did work:

Stuff that didn’t work:

• .htaccess redirects – I came mighty close with some mod_rewrite rules, but to be honest even if I had eventually got the proper ruleset set-up, copying/pasting the cryptic stuff for every article would have been very time consuming. Of course the plus side had it worked is that the “old” url’s wouldn’t even be accessible anymore, so there wouldn’t be any risk of someone linking to the depreciated url in the future. Really though, the amount of time required to create a custom rewrite rule for each URL is uncanny.
• Circumventing the existing META tags for each article – I assumed this is a loophole that would have been closed for security reasons, but I gave it a try anyway. The thought being that if you edit one of the existing META’s for an article, you can inject whatever you want into the HEAD section by closing the tag, and then inserting a new one (without closing it). As I suspected, one of the dev’s obviously thought of this, and any quotes you enter are stripped when you save the article.
• Common SEF plugins – The largest “canonical” plugin I found seemed to be more for redirecting a www to a non-www. I didn’t try it myself, but it really looked like it was designed for large-scale site-wide changes.
• Template modification – If you look back at a couple articles I wrote back in Feb (2009), you can use PHP to stuff some head tags whereever you want them. Unfortunately this would be even messier to do than setting up .htaccess stuff and would make for a very large PHP file. It also doesn’t make sense to spend the time stuffing canonical into the head section this way when spending the time on .htaccess would give *redirects* which are *better* in this case. A bad solution for many reasons, so I didn’t even bother.

What did work:

• There is small, relatively unknown plugin for Joomla called “JosTag”. Turns out it’s all that I needed.

You can find it in the Joomla Extensions Directory, or right from the developer’s site. The site is mainly french, but there’s enough english to get you by – the instructions after you install it are dead-easy.

Install it, enable the plugin, and then it’s simply a matter of throwing {tag}whatever-you-want-in-the-head{/tag} in each of your content pages. So for a canonical entry, something like this:

{tag}<link rel=”canonical” href=”http://www.website.com/current-friendly-url.html”/>{/tag}

You can stick it anywhere in the content. The downside is that you obviously have to do this for each content page, meaning you’ll have to know the “desired” url. On the plus side, it’s easy to do (especially compared to the above options), it gives you full control for each page, you can stick other stuff in the “head” section if you want it later, and it’s free.

In any case, if you’ve got the default

Great Success !
Apache is working on your cPanel^® and WHM™ Server

message, you can simply rename the index.html file and place your own at:

/usr/local/apache/htdocs

I did this using SSH and creating an index.html using nano. I’m not sure if it’s actually possible to browse through the server using WHM, so you’ll probably have to either SSH or FTP into your server (optionally, the Virtuozzo control panel seems to let you browse the hard drive and edit files… if you’re using Virtuozzo anyway).

Installed Joomla, restored the database, restored the template folder, and then started installing Extensions.

First up was JCE. I downloaded the lastest version, tried uploading/installing it from within Joomla’s Admin Panel, and then got the following message:

JFolder::create: Path not in open_basedir paths

Oh boy! Not so good.

Did a little searching around and came across some fixes, although the fix in my case turned out to be pretty easy.

Problem: The temp (tmp) folder wasn’t writable. You can check this from Joomla’s administrator panel by clicking Help, System Info, then choosing the “Permissions” section. unwritable = bad.

Solution: Actually, it’s just that the path set up while on the old host was different from the new host. All it takes is a different username, or a whack of other things. All you have to do to fix it, is drop into Global Configuration / Server and set the Path-to-Temp-Folder.

If you’re not quite sure what to enter, go back to the Help / System Info section and look at the last 4 entries (log, cache directory). Hopefully one of them’s pointing correctly and you can figure it out from there.

If not, try:
/home/username/public_html/tmp
…where username is your username (if you’re not 100% sure and are using CPanel you can open CPanel’s File Manager and look far at the left – you should see /home/something at the top of the directory tree. That something is the username.

If your Joomla install is in a sub-domain or addon-domain, adjust appropriately:
/home/username/public_html/my_website_directory/tmp

If you’re still having issues but are positive the path is correct, see if the tmp directory exists. If it doesn’t, try creating it and set the permissions to 777 while you install the program (then try lowering the permissions afterwards to help out security-wise).

There are many factors to consider – maintenance, uptime & reliability, costs, speed, ease-of-use, and more.

We’ll start with a few pros and cons of each, looking at it from a typical VPS point of view:

Self Hosted
Even for those who aren’t saavy enough to manually configure BIND, self-hosted is often an option that’s made readily available. WHM / CPanel for instance will happily set up BIND and DNS servers for you during install, and will let you set up or modify host records with relative ease. When you create a website, entries are automatically generated. If you need to set up or modify special host records for some reason, it can all be done from within a control panel.

Pros:

• EASY movement. Since the name servers are part of your VPS, if you ever have to move to another host, it’s a fairly simply backup/restore procedure. On the whole (besides the backup/restore itself) you’re looking at changing IP’s in a couple places for dns1.mainserver.com and dns2.mainserver.com. Even if you have a few hundred websites on that VPS, they’re generally already pointing to dns1.mainserver.com and dns2.mainserver.com.
• Potential for huge uptime. Big DNS-providing companies are periodically targets for DDOS attacks. Namecheap’s DNS servers went down at one point in 2008 due to a DDOS attack. EditDNS was hit with a DDOS recently, although they managed to keep their DNS servers from all being down at the same time. If the DNS pointing to your site goes down, people generally can’t access your site – it’s that simple. Hosting yourself keeps you from being at the mercy of other companies.
• Potential for quicker DNS requests. The first thing that happens when someone types in www.yourwebsite.com is a DNS lookup. Like everything else, if the DNS servers are overloaded, it will take some time before a visitor gets the response. If you host your own DNS and are able to keep the server from being overloaded, you won’t have that issue. Location also matters, and if your VPS/DNS are located near the bulk of your visitors, that’ll help out too.

Cons:

• Potential for more downtime. Yes, contradictory to what I just said above, you could very well have *more* downtime. The problem is, many people who have 1 VPS run the DNS from that 1 VPS. Any time the VPS goes down, even for a restart, the DNS servers running from it aren’t available. This isn’t good – particularly because DNS results are cached. Caching itself is a good thing, but if someone tries to visit your site and the failed DNS result is cached, they may not be able to visit your sites again until that cache expires, even if your site is back up and running before then.
• Extra load on your sever. It’s another service you have to run on your VPS, and it has to serve requests. Granted, it’s not likely to contribute a lot of load or use a lot of memory compared to other things (webserver, SQL, etc), but it’ll be using some resources.
• It’s an avenue for you to be attacked. It’s one more thing you have to keep up-to-date to keep vulnerabilities at bay, and if someone decides to target your DNS server in a DDOS attack, your little VPS probably won’t fare as well as a larger host.
• You need an IP address for each DNS server. If your host doesn’t provide a few for free, you’ll generally have to pay extra.
• To maintain anywhere near 100% uptime, you often have to set up DNS servers on multiple physical hosts in various locations. Things like WHM / CPanel’s DNS ONLY make this a little easier to set-and-forget on the management end of things, but you’re looking at added cost for additional VPS’s or servers to host these on.

DNS Servers through your domain provider
Often, large domain providers will have their own DNS servers that you can use (Namecheap for example). As long as your provider allows you to set up all the host records you need, it’s not necessarily a bad thing.

Pros:

• You don’t have to worry about maintaining/updating the DNS servers. Your provider does.
• No DNS overhead. Less of your own resources being used.
• The provider worries about DDOS attacks – you don’t have to.
• Often free for all the domains you host through them.

Cons:

• You have to set up EACH domain to point to your server’s IP. If you have 100 websites, they’ve all got to be set up through the domain provider’s control panel to point to your VPS’s IP address.
• If your IP address ever changes (for example if you move your VPS to another host), every website you host needs to change the IP address.
• Any host records have to be set up with the domain provider.
• Because of the above 3 issues, you can/should only use this for a VPS that hosts websites that YOU own. If you have customers that you host, this is not going to be an option.
• Because this is a “free” option, the domain provider may not be terribly concerned about making sure their DNS servers are quick, responsive, and underloaded. Your mileage may vary.

DNS Servers through your VPS host
Many VPS hosts also allow you to use their own DNS servers. The pros and cons are very similar to the above case. If you have customers, it’s still not a great option – they’d have an easier time simply pointing domians to your VPS host’s nameservers, but you’d have the work of manually setting up the IP’s in your VPS host’s control panel. You’d also be responsible for setting up any/all extra host entries manually. Basically, it becomes less work for your customers, and more work for you.

Use a dedicated DNS service
There are quite a few out there. Most of the time they cost money if you want them to be fully-featured (some have free options with limitations in place). If you look around, you’ll find some that serve the DNS requests from multiple locations around the world which can help for a speedy experience for viewers. They’ll usually provide a large number of DNS servers also which really decreases the chance of downtime. Of course, this isn’t a customer-friendly option, but since these companies specialize in DNS serving, there’s the potential for the fastest, most reliable DNS you’ll find (outside of an expensive self-hosting solution).

So what’s the best option?

If you’re hosting customers, you’ll probably want your own DNS servers, spread across multiple machines, with a control panel that integrates those servers well. Let’s face it, dns1.yourwebsitename.com looks more professional than other options, and it makes it much easier for the customer to simply point their domains there. However, some DNS providers offer “vanity” DNS names, which allow you to use their DNS servers but keep a dns1.yourwebsitename.com style, so that may remain an option.

If you’re hosting your own small or medium-sized sites, you’ll probably want to go with DNS provided by either your domain provider or your VPS host. This will take a little work off your VPS, and you won’t have to worry about patching any DNS exploits. Chance are, your VPS will be down more often than their DNS servers (unless you never restart and nobody else manages to crash the VPS), although you may want to do a little searching beforehand on your specific VPS host or domain provider to see if they’ve had downtime on their DNS in the past and how long it lasted. The big plus here is that it’s typically free to use those DNS servers.

If you’re hosting your own large sites, you’ll probably want to go with either a few of your own dedicated DNS servers hosted in various locations, or a specific paid DNS service. A paid service often costs less than buying servers simply for the sake of DNS hosting, but weigh the pros and cons and decide on your own.

———————————————

In the event that you’re not using your own DNS servers, a couple areas you may want to look at (regardless of who you choose as your host) are:

• Reliability of that particular host
• Distance from the host’s DNS servers to the location your traffic comes from.
• How responsive the DNS servers are (do a few tests at different times during the day to see how long it takes for a DNS request to resolve.
• How many DNS servers they offer (redundancy)
• Whether they’re able to serve requests from multiple servers in various geographical locations (Anycast).

I did all the steps – I unlocked the domain from GoDaddy’s control panel, then placed the order through Namecheap. Namecheap needed the EPP code – I used the GoDaddy control panel to email it to myself, and entered it on Namecheap’s site.

All seemed to go well until it got “stuck”. For a few days at that. A little searching around showed that it may take up to 5 days, but the odd thing was checking Namecheap’s Transfer Status page, the status description was “Transfer in Process – Acquiring Current Whois for Transfer Verification“.

Should it take over 2 days for a Whois lookup? I think not.

Although I had searched searched Google with terms similar to this page’s title, I hadn’t come across anything for this situation. I searched for “Transfer in Progress – Acquiring Current Whois for Transfer Verification” this time, and BAM, came across this Namecheap KB article. Basically it states that the status description I’ve been getting happens if the auto-whois that Namecheap does during a transfer doesn’t get anywhere for 8 hours. The transfer is effectively “stuck” at this point. Fortunately, that KB article gives instructions for opening a ticket to get it manually fixed (although it’s unfortunate that someone could be waiting for days before deciding to submit a ticket – would be nice if it was automated).

I opened a ticket at Medium priority and got an email 5 minutes later stating:

This happened because the current registrar is blocking our IP addresses for whois queries and we’ll have to manually insert whois details into the form. We have forwarded these details to our development team to investigate this further and manually update the whois info. Please allow up to 24 hours to receive the authorization email. Please use that time to unlock your domain, take off any whois privacy features and ensure that admin contact’s email is valid and checked frequently.

Thank you for letting us know about this problem.

In any case, a 5 minute response time by Namecheap is pretty impressive. All the steps they mentioned had already been taken, so it’s just a matter of sitting and waiting for the authorization email. I’ll update the post if there are any further issues.

Update: There weren’t any further issues. I got an email from eNom (Namecheap’s provider) with a link that I had to visit to authorize the transfer. GoDaddy sent me a mail at that point letting me know there was a transfer request. To make things speedy, I logged into my GoDaddy account, found the domain, looked at the “Pending Transfers” section, and approved the transfer. Less than an hour later, I got an email from Namecheap stating that the transfer was complete.