Skip to main content

White Label DNS with Amazon Route53

amazone-route-53

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 Amazon 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 Amazon Route 53 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’.

route53-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:

route53-domains

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 Amazon 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.

route53-reusable

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.

route53-mass

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.

13 thoughts

  1. Gavin -

    Thanks for this post, I’ve been considering using Route53 for a while…

    Is there any workaround to the Plesk subdomains creating conflicting zones limitation? Is there someway to manually correct it? It’s a bit of a deal breaker if subdomains can’t be used.

    Thanks.

    Reply

    Eugene Kazakov -

    Subdomains should work without separate zone, but adding records to the zone of parent domain.
    This is default Plesk behaviour. Why don’t you follow it?

    Reply

    Gavin -

    I’m referring to this in the post:

    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.

    I took this to mean that creating a subdomain in Plesk would cause this conflict error — is that no the case?

    Reply

    Peter Jaffray -

    It’s not the case. I ran into the issue he was describing when I tried to create a seperate zone for ns1.mysite.com when I should have just edited A “ns1” inside “mysite.com”.

    Basically, don’t treat a subdomain like it’s own domain. So long as you keep all records for “mysite.com” in the same zone it’s a breeze. This is the default for plesk so you will have no issues.

    Reply

  2. can ho m one -

    thanks this post, i done it well.

    Reply

  3. Mike -

    I don’t understand this tutorial… These are the steps I took:
    1. Register domain at Company A, example.com
    2. Add to Hosted zone
    3. Took the 4 nameservers Amazon AWS provides and updated the nameservers from the domain I registered at company A.
    4. Installed the extension and added the secret keys.
    5. Added the domain to Plesk.

    Do I now have to add the domain and subdomains like ns1.example.com & ns2.example.com in the domains section of plesk?

    Can I still run a website on example.com? I think I am missing the link between the domain and the webserver where Plesk runs on. Do I need to create a A record with the IP adress from the plesk server? If so, is that really white label?

    Hope you can answer these questions, I have been going through this tutorial over and over, but can’t seem to get to the right results.

    Thanks

    Reply

    Eugene Kazakov -

    Hello Mike,

    Your steps are correct.
    Next if you want to register example2.com and example3.com, you might do not want to repeat the step “Took the 4 nameservers Amazon AWS provides and updated the nameservers from the domain I registered at company A” and use ns1.example.com and ns2.example.com instead. Because it is desirable in most cases described in the article.

    So, I suggest to continue with the following steps:
    6. Create A records ns1.example.com and ns2.example.com (not subdomains in Plesk, but only DNS records in the zone example.com) with IP addresses from Amazon nameservers (see Reusable Delegation Sets).
    7. Register example2.com and example3.com with nameservers ns1.example.com and ns2.example.com

    The domain example.com could be used for website, the web server do not affect DNS resolving.

    Reply

    Peter Jaffray -

    Do I understand correctly? Great resource btw…

    Registering a delegation set means allowing you to point at the IP addresses of the r53 nameservers with a A-record directly.

    Set your DNS template to create the following for new domains:

    Mydomain.com
    NS – ns1.mydns.com
    NS – ns2.mydns.com

    Then new domains will use the nameservers as below:

    mydns.com
    A ns1.mydns.com – 123.123.123.123 (IP of ns-123.awsdns-123.net – delegation set)
    A ns2.mydns.com – 234.234.234.234 (IP of ns-234.awsdns-234.net – delegation set)
    A mydns.com – 1.1.1.1 (IP of website – doesn’t matter)
    NS – ns-123.awsdns-123.net
    NS – ns-123.awsdns-123.com
    NS – ns-123.awsdns-123.uk
    NS – ns-123.awsdns-123.org

    My question is, do the NS records of mydns point at r53 nameservers still? Can this hurt or is it better?

    I am new to this… I hope I understand.

    Reply

    Eugene Kazakov -

    It doesn’t matter who resolves the zone mydns.com.
    There is no problem to host the zone on AWS.
    I think it’s much better to use one provider than several different.

    Reply

  4. Peter Jaffray -

    One more question. Thank you so much for your time.

    If I edit domains on r53 directly, how do I pull the settings into Plesk (or do I need to re-create all inside plesk)?

    Reply

    Eugene Kazakov -

    The ability to pull something from r53 is not implemented now.
    A synchronization in both direction is always complicated.
    Why do you need this?

    Reply

  5. Peter Jaffray -

    I’ve got it working, however new domains do not get assigned the NS records according to the template (on AWS). They get the generic amazon names (ns-123.awsdns-123.com).

    Is there a setting somewhere that I am missing which will give new domains my private ns records?

    Reply

    Eugene Kazakov -

    AWS always shows own names – because it is real names on name servers.
    Believe the address you enter on domain’s registrar form.
    And check what the dig ( https://toolbox.googleapps.com/apps/dig/ ) shows.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *