Zerigo Blog, Articles, & News

DNS adds IDN TLD support

2010-08-23T22:28:00Z

We’ve enabled full IDN TLD support within Zerigo DNS. If you’re not well-versed in DNS-related acronym soup, you’re in good company. So, let’s explain.

The DNS system was built around a basic set of characters, primarily alphanumeric, with a couple symbols thrown in. For English speakers, this is perfectly adequate. For speakers of other latin-based languages, it may not be quite ideal, but it’s not too bad since the alphabets are similar.

However, speakers of other alphabets and languages have found things to not fit so well. With that in mind, the powers that be began to work on on a solution quite some time ago.

Several years ago, they brought us the Internationalized Domain Names, or IDN. This is a way of encoding any Unicode character into something that fits the existing DNS system using a process called punycode. You can recognize an IDN domain name because it starts with “xn--”, for example: xn--hxajbheg2az3al.com.

Zerigo has supported these all along. However, notice the .com on the end. That’s the TLD (top level domain) and it’s still in a latin character set. The next step in the IDN process is to make it possible for those to be in native languages too.

That brings us to today. Starting in May, ICANN formally launched a handful of IDN TLDs. They’ve added a couple more since May too. Appropriate registries in the countries that have been assigned IDN TLDs are just now in the process of making IDN TLD domain registrations available.

The new TLDs also use punycode. For example, Russia’s new IDN TLD is .xn--p1ai (which is the two cyrillic letters for RF, Russian Federation).

We’re pleased to support all of the TLDs that ICANN has approved as of today. For the IDN TLDs that are issuing domains now, you can use those domains with Zerigo today. For the IDN TLDs that have been approved but domain registrations are still pending, we have everything ready.

Currently supported IDN TLDs are for China, Egypt, Hong Kong, Russia, Saudi Arabia, Taiwan, and United Arab Emirates (list).

Using our example above, a full IDN domain in our system might look like:
xn--e1afmkfd.xn--p1ai.

ICANN will be assigning more of these TLDs in the coming months and we’ll be adding them to our system too.

As always, if you have questions, don’t hesitate to contact us.

Zerigo Update 2

2010-07-23T21:13:00Z

As we began a few weeks back, here’s another update on a variety of recent changes. With that background, on to the July 23rd edition of updates….

Let’s tackle a bunch of DNS items first.

Notes

First, notes (aka comments)! Need to remember why you added a specific host record? Or keep track of a planned, future change? Domains, host records, template, and template host records all now have the ability to store notes to help you keep organized.

Statistics

We’ve also recently added some charts/graphs to help visualize the traffic to your domains. To make room, we’ve added a Statistics tab to each domain which shows, well, stats for that domain.

Consolidated stats, for all domains on your DNS plan, are also now displayed in a new chart on the Service Overview page.

Then, for customers using our Custom Logic DNS Instances, traffic statistics for those instances is now available under Custom Instances—both per-instance counts and a chart showing aggregate usage across all instances.

All of these charts are dynamic and will show the exact query counts for each day by hovering over the graph point for that day. Everything’s done in HTML5 or SVG (depending on your browser) so it’ll work on any recent platform, even those that don’t support Flash.

Slave domains

A new option has been added under Tools for slave domains: Reload from master. This option forces our dedicated AXFR transfer servers to reload the domain’s data from your master server. It isn’t usually needed, but if something gets out of sync with the automatic update process, this should put it back together.

The most common case is when the zone serial number on the master server has gone backwards. This option will force a refresh regardless of the serial number (or much of anything else).

API

We’ve shown the API some love too. The notes field is available in all four relevant resources (zones, hosts, templates, template_hosts). Also new is the tag-list field for zones that exposes the currently assigned tags for a domain. Both notes and tag-list are read/write.

We’ve also added a new stats method for zones that will return the current query count along with the dates of the current monthly cycle.

The API documentation has been updated to reflect all of the above.

Security

We know that each of the services we offer is often critical to what you do. Accordingly, the security of your services is really important. Effective immediately (really, as of a few hours ago), we’ve tightened the security of login sessions.

While there are several things we’ve changed, the most significant is that we’re now tying your session to your IP. If you change networks, you will be required to login again. If your environment uses multiple proxy servers (or otherwise causes you to access our site from multiple IPs), you may be logged out frequently. If you have any trouble, please contact support.

Wrap up

Many of the things we add and implement are the result of suggestions and feedback from many of you—thank you!

As always, email support if we can be of help in some way.

DNS Upgrade Details: Slave Service

2010-06-11T06:05:00Z

This post provides additional information about our global DNS network upgrades as it pertains to using our Slave DNS service. If you haven’t yet heard about our network upgrades, then that’s the place to start.

Another post discusses the changes for our Standard and/or Standard with Master DNS services (also including custom/vanity nameserver use for all services).

What changes do I need to make?

There are two potential changes for domains that use our Slave only service.

1. If you use vanity names for our nameservers, you will need to change IP addresses of the vanity nameservers. Since this also affects our other services, details are in that post: DNS upgrades: Standard and Standard with Master services.
2. If you restrict AXFR transfers to our IPs, you will need to allow transfers from the new IPs of our designated slave zone transfer servers. If you restrict transfers by domain name, then you probably will not need to make a change (unless your nameserver software caches the results).

The designated zone transfer server IPs will be changing as follows:

s1.ns.zerigo.net — 64.27.57.11 → 68.71.141.22
s2.ns.zerigo.net — 208.78.96.210 → 174.36.24.251

We strongly recommend adding the two new IPs to your allow list immediately, while leaving the old IPs in the list for several days. Zone transfer request attempts have already begun on the two new servers. This should allow you to check your logs to confirm that we are able to receive transfers on the new IPs. Feel free to contact our support team to verify it from this side if you’re unsure.

The server names (s1.ns.zerigo.net and s2.ns.zerigo.net) will point at the old IPs until Wednesday, June 16 at 10:00am MDT (16:00 UTC). After that time, they will point to the new IPs. This should only matter to those restricting transfers by domain name.

In order to avoid any interruption in receiving updates to your zone records, we will continue to make zone transfers requests from the old IPs for several days. Once our systems confirm that we can receive zone transfers from the new IPs, we will use those servers as the source of your zone transfer data. We will also be following up with you via email if we see that the new IPs are not able to communicate with your master.

Once you see successful AXFR transfers from both of the two new IPs, you can be assured that the transition to the new slave zone transfer servers will be smooth and that updates will continue to be received by our servers from your designated master.

After the old servers stop making requests to your master, you may safely remove the old IPs from your allow list.

Additionally, if you have been using s1.ns.zerigo.net and s2.ns.zerigo.net as the names of our nameservers for DNS traffic (that is, those names are associated with NS records for your domain), please change to using any or all of a.ns.zerigo.net though e.ns.zerigo.net. s1 and s2 are only the addresses we make zone transfer requests from and are not our standard nameservers.

If you have questions or comments, please send us an email.

DNS Upgrade Details: Standard Service

2010-06-11T06:04:00Z

If you’ve already read about our global DNS network upgrades, then this post will provide some extra details about how those upgrades impact our Standard and Standard with Master DNS service (and custom/vanity nameservers too). If you haven’t heard about the upgrades yet, read our DNS network upgrade announcement first.

A separate post outlines the changes for our Slave only services.

What changes do I need to make?

If you use our Standard and/or Standard with Master DNS services but do not use custom/vanity nameservers (that is, your domain’s nameservers are a.ns.zerigo.net and so on), then you don’t need to make any changes. Everything related to our upgrades will be fully managed by us and transparent to you.

However, if you use custom/vanity nameservers, then you may need to change IP addresses of your vanity nameservers. IP address changes need to be made in two places:

In the actual domain configuration (in Zerigo’s control panel).
Your registrar’s glue records

For most cases, we recommend the following IP exchanges:

208.78.96.210 → 174.37.229.229
64.27.57.22 → 174.36.24.250
194.96.227.67 → 72.26.219.150

However, if you use fewer than all of our nameservers, you may with to reevaluate your choice of servers based on geographic locations.

When is all this happening?

We began migrating the DNS records for the three relocated servers (b.ns.zerigo.net, d.ns.zerigo.net, and e.ns.zerigo.net) at the time the initial announcement was published.

For users of custom/vanity nameservers, you may make the change in your domain records and at your registrar at any time. All of the new nameservers are fully functional now. We encourage you to make the changes as soon as possible.

The old nameservers will remain running until all traffic has moved. We’re optimistic that this will be complete in July—to that end, we’ll send out reminder emails periodically to those that haven’t moved things over. However, we are committed to ensuring a seamless transition without any interruption.

If you have questions or comments, please send us an email.

Upgrades to our Global DNS Network

2010-06-11T06:03:00Z

We’re very excited to announce big upgrades to our global DNS network today.

Earlier this year we set out to review our current DNS network and asked ourselves several questions: How can we improve overall service? What changes do we need to make to support our continued growth? What can we do to improve the resiliency of our network?

We identified several goals:

Locate nameservers in cities that are key bandwidth hubs.
Connect our nameservers to more networks and providers.
Increase capacity and make it easier to add even more.
Improve overall network resiliency.
Slave nameserver functions should be operationally separate from DNS query resolution functions. (This alone would have avoided most of the partial outage on June 9th.)
Upgrade other aspects of our nameserver deployment to prepare for the future.

To this end, we are making the following changes:

1. Adding DNS service in Dallas, Texas, USA; Washington, DC, USA; and Amsterdam, Netherlands. All three of these locations are significant hubs for internet traffic.

The new locations all meet several criteria for our future plans—covering our continued growth as well as new features we intend to offer. The chosen datacenters all have significant networks and fiber connections which will offer better connectivity and lower latencies to a larger number of end users.

All three of the new locations are replacing existing locations:

b.ns.zerigo.net — St. Louis → Washington, DC
d.ns.zerigo.net — Denver 2 → Dallas
e.ns.zerigo.net — Vienna → Amsterdam

2. Moving slave nameserver functions and making them operationally independent of normal DNS resolution. To facilitate this, both of our official slave zone transfer servers will receive new IPs (and one will be moved to one of the new datacenters). DNS query resolution for slave zones/domains will continue to be processed by our standard production nameservers.

How does this affect you?

Unfortunately, changes of this scope require changing the IPs of the relocated nameservers. Depending on how you use Zerigo’s services, you may or may not need to make any changes on your own.

We’ve posted two additional articles with detailed information on the changes:

If you use our Standard or Standard with Master services and do not use custom nameservers (your domain is configured to use “a.ns.zerigo.net” and so on), then no changes are necessary on your part. We’re able to handle everything for you. The extra articles may be informative, but are not critical.

If you use custom/vanity nameservers, please be sure to read the first article.

If you use our slave service, be sure to read the second article. If you also use custom/vanity nameservers, read both.

Additional thoughts

As we noted in Wednesday’s post about the partial DNS service outage, we already had a project in place that would significantly reduce the risk of another outage like yesterday’s. This is that project and we’re pleased and grateful that we were already so far along and that we are able to begin the deployment phase today.

We will also be sending out email to everyone who we believe has to make one or more changes to their domain and/or master server configuration. The extra articles mentioned above have all the necessary information, however; so there is no need to wait on that email if you haven’t received it yet.

We considered the possibility of making these changes one at a time, spread out over several weeks. However, because some customers could end up making multiple changes that way, it seemed better to do everything at once.

After the changes, our global nameserver network will look like this:

a.ns.zerigo.net – Denver, USA
b.ns.zerigo.net – Washington, DC, USA
c.ns.zerigo.net – London, UK
d.ns.zerigo.net – Dallas, USA
e.ns.zerigo.net – Amsterdam, NL

To everyone who made it this far, thanks for reading!

As always, if you have questions or comments, please send us an email.

This morning's DNS issues

2010-06-09T15:26:00Z

As many of you already know, we had a partial DNS outage this morning.

Two of our nameservers were affected: a.ns.zerigo.net and b.ns.zerigo.net. The others continued to function fully.

Initially the affected nameservers failed to respond to only some DNS queries. Due to secondary effects, this cascaded into complete DNS resolution failure for the affected nameservers. The total time of less than 100% DNS query resolution was just under two hours.

Each affected nameserver handles two separate DNS functions for our network: standard DNS query resolution and slave zone transfers from external masters.

This morning’s problems surround the latter operation. Malformed data from a zone transfer caused the nameserver processes to die repeatedly. The malformed data is a narrow, specific edge case and has been identified. Obviously the nameserver processes did not properly handle this particular data. We will be working to get this fixed.

Our DNS servers also each run an additional guardian process designed to restart the nameserver process in the event that it dies. While the guardians did restart the nameserver processes for a while, in the face of nameservers repeatedly dying, the guardians eventually failed. We will also be working to get this resolved.

We already have a project underway that includes separating all zone transfer functions from all DNS resolution functions. Had this project been finished and deployed, today’s issue would have been much more contained: only zone transfers would have been affected and DNS query resolution would have remained at 100%.

The good news is this project (which is broader in scope than just relocating zone transfer functions) is nearly complete. We are going to accelerate the final deployment of the entire project. More news about that transition will be published this week.

We sincerely apologize for today’s DNS outage. We know we have let you down. As outlined above, we’ll be making specific changes going forward to not only address the particular causes of today’s issues, but also to improve our network’s resiliency to the unexpected.

Please do not hesitate to contact us if you have any remaining questions or concerns.

Fedora 13 images, DNS updates

2010-06-08T16:01:00Z

For all the Fedora fans out there, we now have a Fedora 13 base image for our VPS’s and Cloud Servers.

Fedora 13 is available in both 32-bit and 64-bit variants.

On our DNS platform we have promoted AAAA records (used for IPv6 addresses). Previously AAAA records were only available with Advanced Options enabled. Now they’re visible to everyone by default.

Additionally, we have added support for SPF and NAPTR records.

Originally SPF text records all used a DNS TXT record. This still works. However, there is now an official DNS SPF record. You may continue to use TXT records or you may switch to the newer SPF record type.

NAPTR records are commonly used for mapping phone numbers to SIP servers and other similar things. Enable Advanced Options in Preferences to be able to use NAPTR records.

Both SPF and NAPTR are fully accessible via the API.

Updated Server Images for CentOS and Ubuntu

2010-05-25T17:31:00Z

We have three new server base images available today:

CentOS 5.5 – 32bit & 64bit
Ubuntu 9.10 – 32bit & 64bit
Ubuntu 10.04 – 32bit & 64bit

CentOS 5.5 appears to be a fairly straightforward update. Upgrades from an existing image to 5.5 are likely to work without problems. Don’t forget that you can always take a snapshot first so that if something does go wrong, you can restore back to where you were.

Ubuntu, as is typical, changed some fairly substantial things in each version. Neither 9.10 nor 10.04 will run on the 2.6.18 kernel that currently runs on most servers. Do not upgrade your existing Ubuntu server to 9.10 or 10.04 until the kernel has been upgraded. You can see the currently assigned kernel in our control panel: Servers → (your server) → Configuration → Kernel.

This, of course, begs the question, “How do I upgrade the kernel for my Ubuntu server?” Just contact support and we’ll take care of it for you. There are a handful of small, but important changes that coincide with an updated kernel. We’ll shutdown your server, upgrade the kernel, make all the other changes, and boot things back up. It should only take a few minutes.

Once the kernel’s upgraded, you’ll be ready to upgrade Ubuntu itself. We strongly recommended taking a snapshot of your server first so that if something goes wrong, you can restore back to where you were.

Zerigo Update

2010-05-21T20:23:00Z

We thought it’d be interesting to provide an update of some of the smaller changes we’ve made recently, along with at least some news on what’s to come.

DNS now support uploads of BIND-style data files. This is in addition to the existing domain import functionality.

We also recently enabled pre-loading of some DNS nameserver information. In many cases, this will mean you will no longer need to wait on the active nameservers list to load.

Several small UI changes to Servers. Cloud servers now show the number of unbilled hours. A little more information about each server’s configuration is also now provided, including the current kernel version.

We have newer kernels and some new images (Ubuntu 9.10, 10.04, and CentOS 5.5) in testing now. If the testing continues to go well, we’ll make them generally available soon.

If you find this kind of update useful, let us know and we’ll do it more often.

New: Custom Logic DNS Instances

2010-05-21T14:57:00Z

We’re excited to announce the availability of our new Custom Logic DNS Instances.

This new service provides an ultra-flexible managed DNS platform capable of processing DNS queries using your own unique criteria and intelligence. The custom logic is implemented in a custom processing module that’s deployed as one or more processing instances.

End result is Zerigo’s managed DNS network running with your custom intelligence.

More details along with some example use-cases are available here: Custom Logic DNS.

New VPS Beta Image Program (aka How to get a free Zerigo VPS)

2010-04-02T15:26:00Z

We’re pleased to announce our VPS Beta Image Program. Here’s the scoop:

We’re working on several new and updated base images for our Servers. Some changes are in the images themselves. Others have to do with the Linux kernels. While in the past we’ve done our best to test everything (and we’ll continue to do so), we figure that the images can be even better with the help of our customers.

So, we’ll give you a free 360 VPS for a month (and 40GB of bandwidth) to help us test a new image and/or kernel. After the month is up, it’s your choice whether to keep the VPS (and start paying for it) or delete it.

This is also a great opportunity to provide feedback and help us improve the images.

It probably goes without saying, but you do have to stay with the test image and/or kernel for the whole month (although we may give you the chance to try a different image or kernel along the way); you may not revert to a standard production image or kernel.

Please be aware that new kernels in particular may be prone to unusual behavior. While you are more than welcome to run your own stuff on your test server (in fact, we encourage it), please stick with apps where you can afford downtime, in case that happens.

You do need to already have a Zerigo login to apply. You do not need to have an existing Server. There are a limited number of slots available at any given time, depending on what we have to test at the moment.

Sound interesting? To apply, login and go to Servers → Beta Programs.

Upgraded VPS Plans

2010-03-25T16:47:00Z

It’s another great day in Zerigo-land. We’re excited to let you know that we’ve upgraded our VPS plans.

Now, for just $19/month get 360 MB of RAM and 16 GB of storage. The other plans scale up proportionally.

The new plans are:

RAM		Storage
360 MB	-	16 GB
540 MB	-	24 GB
720 MB	-	32 GB
1080 MB	-	48 GB
1440 MB	-	64 GB
2160 MB	-	96 GB
2880 MB	-	128 GB
3600 MB	-	160 GB
4320 MB	-	192 GB

See VPS pricing for full details.

Existing VPS customers may Resize to any of the new plans at any time. Due to the disk size changes, the Resize operation will take a few minutes (depending on much storage is actually in use on the disk). If you’d like to upgrade everything except the disk (meaning just a reboot instead of a complete resize operation), email us.

We’d love to hear your comments and feedback: talk to us.

The Zerigo team

PS: More goodies on the way soon!

Expanded DNS API and improved documentation

2010-03-18T16:41:00Z

We have two API related items for you today.

First up, the DNS API has been expanded to include Templates. This adds two new resources, zone_templates and host_templates, which are the template equivalents of zones and hosts, respectively.

The updates are backwards compatible, so the API version remains at 1.1

Second, we have improved the API documentation. We’ve broken each API resource and method on to its own page and significantly improved the formatting to be easier to read.

Everything’s still available on a (long) single-page format too if that’s your thing.

Find everything here: http://www.zerigo.com/docs/apis/dns

There’s more API goodness is on the way too—stay tuned!

Are all 32-bit VPS's the same?

2010-03-04T23:31:00Z

There seems to be some confusion about 32-bit VPS’s in the general marketplace. It seems like it might be appropriate to take a minute and look at 32-bit and 64-bit support and how the various options might affect you.

There are in theory three different possible combinations of kernels and userland:

A) 64-bit kernel with 64-bit userland
B) 64-bit kernel with 32-bit userland
C) 32-bit kernel with 32-bit userland

Userland simply refers to everything other than the kernel (system libraries, your applications, etc.).

On the surface, options B and C would seem to be pretty much the same. In many instances they are. However, there are a couple instances where option B turns out to be inferior to option C.

The first is if you are adding any of your own kernel modules. Because the kernel is 64-bit, the modules will need to be 64-bit too. This is certainly doable, but some installation or compilation tools will give you some trouble because of the mix of 32-bit and 64-bit (you will need a compiler capable of generating 64-bit code, along with appropriate compilation flags).

This is related to the second issue: when compiling or installing some software (cpanel for example), the build or install process will determine what architecture to use based on the kernel, not based on userland. This can result in an attempt to install 64-bit software into the 32-bit userland. In theory this can work, but in practice usually won’t because all of the system libraries are 32-bit.

In both instances, having a through-and-through 32-bit environment avoids all these potential problems and hassles.

Consistent with Zerigo’s commitment to making things easier for you, our 32-bit VPS’s and Cloud Servers have a 32-bit kernel and 32-bit userland (option C). And of course, our 64-bit servers (64-bit kernel and userland) are always available to you too.

More DNS API code (yours and ours) and some billing improvements

2010-02-15T15:22:00Z

We wanted to take a minute and provide a few updates.

First up are a few third party DNS API projects we’ve learned about:

For Python, two modules are now available: Peter Sanchez’s zerigodns and Louis Opter’s pyzerigo.

The ActiveResource version of our Ruby code has been packaged up into a Ruby Gem by Tom Wilson: zerigo_dns.

We have also published a minor update to our Ruby example code that works around a bug in ActiveResource where error messages aren’t reported properly. If you use the HTTParty version of the Ruby code, no update is necessary at this time.

This past week we made some improvements to our billing system. Previously, if you had multiple paid services, they could have different renewal dates. This caused some confusion and generally didn’t seem desirable. Going forward, all services will be adjusted to renew on the same day each month.

As a reminder, you change your monthly billing day. When changed, future service renewals will be prorated in such a way as to cause them to align properly on your selected billing day.

Also billing related, you may now enter your tax ID on the Billing Preferences page. When entered, your tax ID will be included on all future invoices. This is entirely optional and is available to help with legal/tax compliance in some countries.

As always, we love to hear from you, so feel free to drop us a line if you have something to say.

The Zerigo team

Build a Server and have your SSH public key baked right in

2010-01-13T15:53:00Z

Happy new year! Here on the 13th day of this fine year we’re excited to bring you the first of many new features.

Starting today, all VPS’s and Cloud Servers may be built with an SSH key for the root login instead of generating and emailing a random root password.

A new tab, Keys, has been added to the Servers management interface. To get started, go there and add your own public SSH key. Be sure to upload your public key, not your private key.

When you build (or rebuild) a server and select one of your SSH keys, that public key will be added to the root user. Additionally, to enhance security, password-based logins will be disabled entirely for SSH logins. You may reenable them by removing the last few lines appended to /etc/ssh/sshd_config.

Password based logins from the console remain enabled so that the ‘Reset Password’ function will still work when combined with a login via the AJAX console.

Creating an SSH key

If you are new to SSH keys, we recommend that you build your server with a root password to start. Learn how to configure SSH key based logins when you have a functioning password and way to login without an SSH key. Once you have the SSH key login worked out then begin to create servers using your SSH key.

On Linux, OS X, and *BSD systems, use the ssh-keygen command. By default, the file ~/.ssh/id_rsa.pub will contain the public key.

On Windows it will vary based on your SSH client. PuTTY is probably the most common; PuTTY’s puttygen.exe application will help you generate keys.

The Keys tab will accept uploads of your public key in a few different formats, so the native formats for both OpenSSH and PuTTY should be fine without any conversion necessary.

Comments/questions

Your comments and questions (and suggestions for more features) are always welcome!

The Zerigo team

Resolving past problems with c.ns.zerigo.net

2009-12-13T16:37:00Z

As some of you are aware, we’ve had some trouble with one of our upstream providers over the last several weeks, causing network access and other problems for c.ns.zerigo.net in London. This provider has been unable to provide us with sufficient assurances that they have the problems under control.

We have consistently committed publicly to doing everything possible to provide the highest degree of uptime. Accordingly, we have moved c.ns.zerigo.net somewhere else that can meet our high standards for reliability and uptime.

The majority of traffic has already moved to the new location. The old location is still answering DNS queries and will continue to do so until all traffic has stopped.

If your domain’s nameservers include “c.ns.zerigo.net”, nothing is required on your part. If you use custom nameservers and have one of them pointed to 83.170.85.203, that IP needs to be changed to 109.74.192.232.

We are sending out email notifications to custom nameserver users who are using the old IP.

Please contact us if you have any questions or concerns about this change.

The Zerigo team

Holiday Cheer: Snapshots for Cloud Servers and Price Reductions

2009-12-09T17:18:00Z

It’s the holiday season here in the US and in many parts of the world. We’d like to wish everyone happy holidays.

It wouldn’t be right if we didn’t spread a little holiday cheer, so here are a couple of goodies for you:

1) Effective immediately, the per-gigabyte price for creating and storing VPS snapshots is being reduced from $0.32 to $0.25.

2) We are eliminating the charge to rebuild a server from a snapshot. You may now rebuild to your heart’s content.

3) There will no longer be a separate charge for downloading snapshots—it will simply be rolled into your server’s bandwidth usage. This should make snapshot downloads effectively free for nearly everyone (if you have leftover bandwidth).

4) We’ve saved the best for last. Snapshots are now available for our cloud servers. Further, they are shared with VPS’s. So, you can take a snapshot of a VPS and build a cloud server with it. Or vice versa.

Snapshots combined with our hourly cloud servers add another dimension to the flexibility that snapshots offer.

For instance, you can fire up a new cloud server to build a custom server image specific to your deployment needs. If you can build it in a few hours, you’ll just pay for those few hours. When you’re finished, take a snapshot. Then, use it to build new servers (VPS’s or cloud servers).

In a couple months when you need to update it a little, launch a new cloud server from that snapshot. Make your changes and take a new snapshot. Instant new base image.

Our cloud servers remain in a invitation-only mode (so we can better manage capacity growth), but invitations are going out regularly, so don’t let that be a roadblock.

While it’s not quite time to get into all the details, we have a big stack of new features and goodies for all 3 of our major services (DNS, Watchdog monitoring, VPS and cloud servers) — 2010 should be a fun year and we look forward to sharing both the year and some great new features with you.

As always, we’d love to hear from you.

The Zerigo team

Fedora 12 image

2009-11-23T23:20:00Z

We now have a Fedora 12 server image available for all the fans of Fedora.

CentOS 5.4 image

2009-11-18T19:06:00Z

The CentOS image has been updated to v5.4.

Additionally, we’ve added a 32-bit version of the CentOS image in case you’d prefer that over 64-bit.