Plesk for Windows
Plesk for Linux
kb: fixed
kb: bug
ABT: Group A
Applicable to:
- Plesk for Linux
- Plesk for Windows
Symptoms
-
NS records created at Domains > example.com > DNS Settings transferred to DigitalOcean incorrectly:
- In Plesk:
ns1.example.com., ns2.example.com.
- After transfer to DigitalOcean:
ns1.digitalocean.com., ns2.digitalocean.com.
- In Plesk:
-
DigitalOcean DNS extension is used on the server.
Cause
Product issues:
-
#EXTPLESK-2403 "The extension again correctly syncs Plesk NS records for vanity and branded nameservers with the DigitalOcean DNS service."
Fixed in:- DigitalOcean DNS 1.2.3 08 February 2021
- #EXTPLESK-634 Open
Resolution
Please consider updating your server:
Workaround
If update is not possible for some reason you may try the following
workaround
Update DigitalOcean DNS extension to the latest available version.
In case the issue persists, ensure that "Sync NS and SOA records" option enabled in the extension settings.
Comments
18 comments
Was just about to report this issue to Plesk support but then luckily found this article!
I found out about this because I'm using vanity nameservers at DO while using the DO DNS Extension for Plesk, so my custom nameservers are indeed constantly being reset to the default three [ns1,ns2,ns3].digitalocean.com after a sync or alteration is triggered from Plesk.
It occurs for example when Let's Encrypt is automatically updating SSL certificates, as it has to update the zonefile in Plesk for validation - hence triggers a sync to DO DNS and 'resets' the NS records back to the default 3 DigitalOcean NS records. Also it deletes any additional NS record (e.g. ns4.mydomain.tld) in DO.
Question about the workaround: currently the version of the DO DNS extension used in Plesk is 1.1.5-51. To use the workaround I need to manually install the older extension version 1.1.4-45, is that correct?
Hello Gerinho Troenokarso
Thank you for the feedback.
Yes, currently, only the version from this article contains a fix.
Please, subscribe to this article to receive a notification in case the article gets updates.
This was a fix for me as well, thank you!
I am getting an error when clicking on a domain in the DigitalOcean plugin listing of domains.
Any help?
Hello Scott Berry
This behavior isn't typical for the extension.
Does the issue persist after extension reinstall?
Consider submitting a request for Plesk Support.
A little tip for anyone with the workaround by using version 1.1.4-45 of the plugin instead of the latest version;
Turn off the Auto-update toggle in Extensions:
This will prevent the DO DNS Extension from automatically being updated to the latest version. I just found out it did that with me and couldn't automatically reissue SSL certificates for the domains on the server.
As a downside, you'll have to update the extensions manually though, so keep that in mind with your server maintenance.
Hi Pleskians,
It seems the issue has returned. I'm currently using DO DNS extension latest version 1.2.0-70 and I did some rigorous testing to be extra sure - as a couple of months ago I had this problem for a while.
As the Symptoms at the top of this page already explains: the NS records in DO are being reverted to ns1.digitalocean.com., ns2.digitalocean.com., while in Plesk I have configured them to be ns1.example.com., ns2.example.com.
How I found the problem occurs again:
I reissued an SSL certificate to a domain that already was synced to DO DNS (with the extension). Then, after looking in DO, the NS records were reverted back to ns1.digitalocean.com, etc. instead of ns1.example.com. First I thought I saw this wrong - because it should be fixed, and it was for a little while - so I tested with 5 other domains after that. To be really sure I checked in DO to see if they still had ns1.example.com NS records before I reissued a SSL certificate. Afterwards all NS records of all these 5 domains were reverted to the default digitalocean.com nameservers.
An extra thing I found out as well: while in Plesk the process of renewing the SSL certificate was running, I accidently found out in DO that it showed me a notification: "The domain example.com was removed" and then after a brief 1-2 seconds, the domain appears back in the list. So it seems the complete domain is being removed from DO and then a 'new instance' of the transferred DNS is being placed in DO - which might explain the 'reset' of the NS records.
This issue is extra inconvenient for us, as we're utilizing DO's vanity nameservers. After each DNS changing trigger, we now need to either manually edit all NS records in DO or else these domains will return errors in DNS lookups (not acceptable).
Can you please have a look at this again?
And is reverting to DO DNS extension version 1.1.4-45 still an acceptable workaround at the moment?
Hello Gerinho Troenokarso,
So far this behavior wasn't reported to us. Do you have the ability to submit a support request to us directly or to one of our partners, depending on where Plesk license was purchased?
Hi Ivan Postnikov, thanks.
I have a Plesk license via a hosting company, because my Plesk instance is bundled with the VPS I rent from them. However, I just spoke to them and because I have an unmanaged VPS they will charge me for filing a ticket through them because this ticket won't be regarding core functionality of the server or Plesk itself. It's the functionality of the DO extension.
This is very cumbersome and I find it unfair that I got to pay, just to get this issue at the guys of Plesk who created the DO extension. Isn't there any other (direct) way?
P.s. the reason why this isn't reported to you is probably because most of the extension's clients won't be utilizing vanity nameservers at DO. In that case, they won't be noticing that the NS records will be 'reset' when the extensions pushes updated DNS records - and it won't be a problem for them either because DNS resolving process still works without any errors. That doesn't take away the problem that, if you create your own NS records in Plesk and need them synced in that manner to DO with the extension, it does not work - exactly as is stated in the symptoms at the top of this page.
Gerinho Troenokarso
Thank you for your answer.
> This is very cumbersome and I find it unfair that I got to pay, just to get this issue at the guys of Plesk who created the DO extension. Isn't there any other (direct) way?
Yes, the 1st month of support subscription is free trial. So, you will be able to submit a ticket to us directly free of charge:
https://support.plesk.com/hc/en-us/articles/213953025
This will speed up the investigation.
Ivan Postnikov
Thanks, I appreciate your will to help me out finding a direct way to get this issue solved. Therefore I will make use of the free 1st month, just to get this sorted out - and because this problem initially already occured since February.
However, as this problem:
I don't think it's a right idea my only 'free' solution is to make use of a 1st free month of Plesk Support. Don't get me wrong, I love Plesk and I'm not against paying for services, but this is a basic functionality of the extension and I'm now sacrificing my 1st free month for it. What if that month has passed and have this same problem again? Is my only way to pay for a solution for problems in basic functionality of Plesk extensions? That's wrong.
To be absolutely certain I'm not wrong about this issue, let me reproduce it again and now with some screenshots for visual guidance of what I'm doing and perceiving in Plesk and Digital Ocean. I'm using the domain mentioned in the screenshots (vapeculture.nl) for example purposes, which runs on our server (Net Supply):
It does. I want the NS records to be ns1,2,3. as you can see above.
FYI: these NS records lead to the three IP addresses of DNS servers of Digital Ocean, which is a method DO provides to utilize vanity nameservers.
At this point the configuration is correct.
Now, I click Update in the right screen and as you can see at the upper right corner in the left screen, Digital Ocean notifies me: "vapeculture.nl was removed from Net Supply". Net Supply being the DO account which our Plesk is synced to via the extension.
So that synced well.
The thing I noticed most is that in DO the domain is first removed and then added back. Of course I can't look into the back end of DO, so I don't know how DO is handling sync triggers but using my technical common sense I'd say the NS records are being reset because a new instance of the domain is added back but with the mutations that come from Plesk. Why? Because the DO's NS records are the defaults - try adding a new domain in DO and the three default NS records are set to ns1,2,3.digitalocean.com. It would make sense if this is the problem.
Hopefully this helps to investigate the issue also.
Gerinho Troenokarso
Thank you for the information and feedback.
We'll keep you informed in the ticket, an investigation from our side is required.
Hello Ivan Postnikov and anyone who might follow this issue here:
It's solved: unfortunately, all these months I have totally missed out on the new 'Allow synchronization of NS records' setting in the extension. Didn't know it was there, until a moment ago I've been requested to check if it's enabled (thank you Robert Asilbekov). And that had been the culprit all the time. So, my apologies for making such a point of the issue, but it's solved now.
And Ivan, considering this was my own fault, now I do think it should cost my free month of support ;)
Many thanks to Plesk Support!
Hi everyone! It seems the issue just came back with the latest update of this extension in January '21. The option "Allow synchronization of NS records" has been activated ever since but when synchronising to DO, all NS entries get lost on DO. When I deactivate the option "Allow sync...", the default DO entries appear, but this is not the preferred usage with vanity servers. Please investigate.
We're currently experiencing the same thing as Ben Hofer mentioned above here.
Result: all domains synced by DO DNS don't have NS records anymore (MX Toolbox reports "no results found").
We also make use of DO's vanity nameservers and it's a severe problem that the extension is removing all NS records / not syncing NS records properly once again.
In upcoming days we have a bulk of DNS changes to process for our clients' domains (due to a change of our transaction mailing system). Now we have to work around it by turning the NS syncing off (as described above as well) and manually add + adjust all three NS records per domain every time the DNS needs to get updated and gets synced.
Can you look into the NS record sync function in the extension again, please?
In case no quick solution is found: do you have a workaround and download to revert to a prior version of the DO DNS extension, which synced the NS records properly? In that case, we can use that as a temporary solution while avoiding manual adding & editing of NS records in DO.
Gerinho Troenokarso, thanks for letting me know I am not the only one experiencing this bug.
Ivan Postnikov, can you tell is if this issue is already known and under investigation? Will it be fixed in the near future? We also find us manually re-entering all NS-Entries with Digital Ocean on their website after any change to DNS in Plesk.
Ben Hofer thank you as well.
I just filed a ticket at Plesk Support with detailed explaining and with it refered to an earlier ticket filed in June 2020 where this issue occured as well.
Just found v1.1.4-45 of the extension in our archived files, which was our workaround version in June 2020 and synced the NS records properly. Currently considering to revert to that version as it is a real PITA to either add or edit NS records in DO every time we do DNS mutations fromout Plesk.
Also, when Let's Encrypt auto-updates SSL certificates, the same problem also occurs silently. The NS records from Plesk are either not transferred or 'reset' to ns[x].digitalocean.com in DO, depending on if you have the "Allow synchronization of NS records" setting active or not. The silent fail of not transferring the proper NS records is a problem too, because having no NS records can cause other trouble for the domains and their functionality.
I can confirm this behavior. @Gerinho can you provide us with a ticket number or even a link to the big report? Thank you.
Ben Hofer
I've filed the ticket but via submitting a request so it's not a page I can link to unfortunately. It's under ID #279626 in any case you're able to look it up though.
However, I got replied that the Plesk devs confirmed the issue under #EXTPLESK-2403 and that it should be fixed and published at the nearest time. Technical Support also asked to prioritize the case, so that the fix should be available really soon (probably today).
Thanks to @... for support and feedback
Please sign in to leave a comment.