• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

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