Plesk

White Label DNS with AWS Route53

AWS Route 53 - White Label DNS via Plesk

Running a shared hosting business can be a challenging and fulfilling occupation, but it does come with its share of headaches. Having hundreds of clients means dealing with lots of domain names, usually managed by different registrars and owned by different persons. Today, I’m going to tell you about a success story of one of our customers who benefited from transferring their DNS service to AWS Route 53.

The first tip, one that can seem quite obvious, is that every domain name managed by a shared hosting company – let’s call it “AwesomeHoster” – should use a pair of its white labeled nameservers ns1.awesome-hoster.com and ns2.awesome-hoster.com. It gives the benefit of not having to remember the exact IP addresses of the NS servers, and also being convenient in case of nameserver migration, as with such setup routing changes do not affect clients.

Should you decide to make the move to the cloud with the AWS Route53 service, we recommend that you use the Plesk extension for automated provisioning of DNS zones to Amazon. First, you need to install it. Log in to Plesk, select ‘Extensions’ from the main menu on the left, and click ‘Extensions Catalog’.

Follow the on-screen instructions to get the key/secret pair from the Amazon portal and enable the provisioning service. Every time a domain is created in Plesk, its DNS zone immediately appears in the Amazon Console:

As you can see in the “Hosted Zone Details” section on the right, the nameservers have names like “ns-1072.awsdns-06.org”. Usually, that would mean that the DNS would not have started to route queries until the nameserver IP addresses were updated by the domain’s registrar. However, since the white label is used, the transfer is transparent for both the customer and the registrar.

Looking through the list of hosted zones, you may notice that each of them has its own set of nameservers. We are going to point the already registered ns1.awesome-hoster.com to every DNS zone on Amazon. For that, we need a common set of nameservers in all zones, called reusable delegation set. This feature is not available in the user interface of the AWS Route53 console, but can be managed with the help of Plesk or the Amazon API.

Let us return to Plesk and take a look at the additional functionality provided by the extension. For example, you can create a new delegation set or reuse an existing one from any hosted zone. To do so, open the extension, go to the “Reusable Delegation Sets” tab and click “Create Delegation Set”. This will produce a single row in the delegation sets list. The row will contain a tuple of 4 nameservers and will be marked as default.

After that, all DNS zones created in Plesk will use the same set of nameservers. It is important to note that due to a restriction placed by Amazon you cannot change the nameservers that are associated with an existing hosted zone, you can only associate a reusable delegation set with a hosted zone when you create the hosted zone. In addition, cleanup in the Amazon Console is rather inconvenient, as a zone can only be removed after all records (except for NS ones) have been removed. Fortunately, the Plesk extension comes with mass management tools (available on the Mass Management tab) that enable you to easily recreate DNS zones of all domains registered in Plesk.

Once the synchronization is complete, you are ready to switch ns1.awesome-hoster.com and ns2.awesome-hoster.com to the IP addresses of the corresponding nameservers (choose any 2) in your reusable delegation set. Open the DNS zone awesome-hoster.com and edit the ns1 and ns2 A records. Take into account that CNAME do not work for nameservers.

To make sure that the DNS queries are routed correctly, you can use the command line utility dig or this online service by Google.

There are a couple of limitations you need to take into account, though:

  • Subdomains should not have their own zone: by default, Plesk creates A record with the name of the subdomain in the zone of the parent domain, but creating a separate zone with the name of the subdomain will result in a “A conflicting domain is already associated with the given VPC or Delegation Set” error.
  • The maximum number of hosted zones that can use the same reusable delegation set is 100 by default, but you can request more.
  • The total number of zones is limited to 500, but you can also request a higher limit.

Along with the high availability, the cloud provider offers scalability features: you can configure DNS health checks to route traffic to failover endpoints, have Geo-distributed traffic around the globe, and more. But this will have to wait until the next time…

I want to thank Erik and wish him success in growing his business.