• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Issue Amazon Route 53 Extension - white label problem

Faris Raouf

Silver Pleskian
Plesk Guru
I've been experimenting with the Route 53 extension and I've hit what is either a technical issue or a possible limitation in the Extension. I can't tell which ;-)

With reference to https://devblog.plesk.com/2016/01/white-label-dns-with-amazon-route53/

When using the Extension to work with whitelabel nameserver records, the problem I'm seeing is this:

When you add a new domain to Plesk and the Extension then creates a new Route53 zone on the AWS side, the NS records that are added to that Route53 zone are the generic aws-type nameservers from the Reusable Delegation Set used by the Extension, and not the whitelabel ones.

E.g. in AWS Route53 for the new Zone:
ns-123-awsdns-12.net
ns-321-awsdns-31.org
ns-789-awsdns-56.net
ns-432-awsdns-67.co.uk

While this is "correct", it does not match the DNS template/DNS records within Plesk, which I had set to be my white-label versions of these records.

E.G: In Plesk's DNS for the newly created domain:
ns1.mywhitelabedns.net
ns2.mywhitelabeldns.net
ns3.mywhitelabeldns.net
ns4.mywhitelabeldns.net
(I'm using four separate nameservers pointing to four different IPs rather than having just two nameservers each with two different IPs which is what is given in the devblog example)

This is a problem because naturally the domain will have been configured at the registrar to use the whitelabel type ns1.mywhitelabeldns.net (etc) nameservers, and this results in some DNS checks report "stealth" nameservers due to the mismatch.

Specifically, these tests warn that that the domain's DNS zone file NS records (which will be ns-123-awsdns-12.net etc) do not match the nameservers associated with the domain (which will be ns1.mywhitelabeldns.net).

You can fix this by manually editing the zone file in Route56, replacing the generic ns-123-awsdns-12.net with the white-label ns1.mywhitelabedns.net etc. The "stealth nameserver" errors go away once you do this.

Unless the Extension is smart enough to look at the NS records in the domain in Plesk, do some forward and reverse looks to check what's what, the Extension will not know what your white-label Nameservers actually are. And thus it isn't going to be able to replace the generic ones with the white-label ones in the way that I want.

So, I'm guessing the problem I'm encountering is just a functionality limit.

Assuming that's correct, please can I request that a feature be added to the Extension to allow the Plesk Admin to it what their whitelabel nameserver records are, which the Extension can then use to replace the generic ones in the Route53 Zone record when it is created?

(or should this be added to UserVoice?)
 
Last edited:
Not really. I have been in communication with Eugene and he was very helpful. He pointed me to the appropriate code.

I took a quick look and although I'm afraid I no longer remember the exact details, I recall at the time that it would be too difficult (for me) to modify it. There were a number of factors involved as I recall.

At the end of the day, however, I am unclear how important having mismatched nameservers in this context really is. I'm not sure it is vital, or causes any significant problem.

I also decided that due to the number of domains we host, it would not be economical to use R56 anyway, so other than for experimentation I've decided not to use it.
 
Back
Top