NS records created in Plesk transferred to DigitalOcean incorrectly

• 

  Gerinho Troenokarso February 11, 2020 16:30

  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?

  0

  Comment actions Permalink
• 

  Ivan Postnikov March 05, 2020 11:33

  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.

  0

  Comment actions Permalink
• 

  Scott Berry March 20, 2020 22:15 (Edited March 20, 2020 22:19)

  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?

  A potentially dangerous Request.Path value was detected from the client (:).
  Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
  
  Exception Details: System.Web.HttpException: A potentially dangerous Request.Path value was detected from the client (:).
  
  Source Error:
  
  An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
  
  Stack Trace:
  
  
  [HttpException (0x80004005): A potentially dangerous Request.Path value was detected from the client (:).]
     System.Web.HttpRequest.ValidateInputIfRequiredByConfig() +11981636
     System.Web.PipelineStepManager.ValidateHelper(HttpContext context) +52

  0

  Comment actions Permalink
• 

  Ivan Postnikov March 23, 2020 12:18

  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.

  0

  Comment actions Permalink
• 

  Gerinho Troenokarso April 16, 2020 12:41

  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.

  0

  Comment actions Permalink
• 

  Gerinho Troenokarso May 26, 2020 23:11

  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?

  0

  Comment actions Permalink
• 

  Ivan Postnikov June 09, 2020 08:27

  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?

  0

  Comment actions Permalink
• 

  Gerinho Troenokarso June 09, 2020 16:55

  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.

  0

  Comment actions Permalink
• 

  Ivan Postnikov June 10, 2020 13:34 (Edited June 10, 2020 13:34)

  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.

   

  0

  Comment actions Permalink
• 

  Gerinho Troenokarso June 11, 2020 14:31

  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:

  • is a core problem of the extension (or in the basic functionality of the extension, if you will)
  • and the problem that occurs is exactly the problem described in this article (and still marked fixed),

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

   

  1.  First, in Digital Ocean I checked if the domain has the right NS records:
     
     
     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.
     
     
     
     
  2. In Plesk, I checked the DNS records, which should be equal:
     
     
     At this point the configuration is correct.
     
     
     
     
  3. Then for the fault reproduction, in Plesk I add a test TXT record, so it (Plesk's DO DNS extension) will trigger a sync to Digital Ocean:
     
     
     
     
     
  4. I submit the text record to DNS in Plesk and update the zone:
     
     
     
  5. Before I click Update in step 4, I've set up to have both Plesk and Digital Ocean next to each other in my browser windows. This way I can capture the mutation notifications from Digital Ocean immediately after I click the Update button to update the zone:
     
     
     
     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.
     
     
     
     
  6. Immediately after DO removes the domain, it adds it back again and now the newly added test TXT record; in DO:
     
     
     
     So that synced well.
     
     
     
     
  7. However, looking at the NS records, they got reset to Digital Ocean's:
     
     
     
     
     
  8. The NS records In Plesk after updating however are the same as in screenshot in step 2. If I now don't manually edit the NS records in DO, the DNS lookups for this domain will resolve with errors.

   

  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.

  0

  Comment actions Permalink
• 

  Ivan Postnikov June 12, 2020 09:44

  Gerinho Troenokarso

  Thank you for the information and feedback.

  We'll keep you informed in the ticket, an investigation from our side is required.

  0

  Comment actions Permalink
• 

  Gerinho Troenokarso June 15, 2020 18:41

  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!

  0

  Comment actions Permalink
• 

  Ben Hofer January 27, 2021 14:43 (Edited January 27, 2021 14:44)

  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.

  2

  Comment actions Permalink
• 

  Gerinho Troenokarso February 03, 2021 01:47

  We're currently experiencing the same thing as Ben Hofer mentioned above here.

  • Just did DNS checks for the majority of all hosted domains of our clients on our servers with MX Toolbox's SuperTool.
    Result: all domains synced by DO DNS don't have NS records anymore (MX Toolbox reports "no results found").
    
    
  • Looked up DNS in Plesk: NS records are still present.
    
  • Looked up the DNS of the domains in Digital Ocean itself and also found that all NS records are gone!

   

  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.

  1

  Comment actions Permalink
• 

  Ben Hofer February 05, 2021 09:57

  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.

  1

  Comment actions Permalink
• 

  Gerinho Troenokarso February 08, 2021 00:43

  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.

  1

  Comment actions Permalink
• 

  Ben Hofer February 08, 2021 08:18

  I can confirm this behavior. @Gerinho can you provide us with a ticket number or even a link to the big report? Thank you.

  0

  Comment actions Permalink
• 

  Gerinho Troenokarso February 08, 2021 11:04

  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

  0

  Comment actions Permalink

Please sign in to leave a comment.