Skip to main content

CPANEL-37035 - DNS Zone Manager issue - literally unplayable

Stacy HM
This results in any attempt to use this tool: API failure: (XID cbu5nu) This system does not have a domain named "(domain)" (domain) is the redacted domain name. This happens when trying to manage a domain, or add any individual record.

Comments

36 comments

Date Votes
  • Metro2
    Well, I thought this was totally resolved with 96.0.10 (and I'm currently now running 96.0.11), but I'm still running into an issue in some scenarios. While the TTL for MX is no longer grayed-out, I just noticed that in some circumstances when I try to change the MX TTL for a customer I'm presented with an error like this: "Error: The request failed. (Error ID: r98pne) Ask your hosting provider to research this error in cPanel & WHM"s main error log." That occurs when I try to change the Google Workspace (G Suite) MX entries from 3600 to 14400 after switching the customer over from Local MX to Google's Remote MX. Happens in both their cPanel and also WHM's DNS Zone Editor. Like just now, I started tail -f /usr/local/cpanel/logs/error_log in SSH so that I could see what error happens in real time, and got this when attempting to change MX TTL from 3600 back to original 14400: [2021-07-02 15:58:23 -0400] info [xml-api] API failure: Zone is invalid: Line 33: TTL set to prior TTL (14400); Line 34: TTL set to prior TTL (14400); Line 35: TTL set to prior TTL (14400); Line 36: TTL set to prior TTL (14400) at /usr/local/cpanel/Cpanel/ZoneFile/LineEdit.pm line 390. [mass_edit_dns_zone] version [1]. Does this post need to be moved to a separate thread? Or is this related to the original issue?
    0
  • cPRex Jurassic Moderator
    That looks like it's related to the updated case I mentioned, CPANEL-37558. We're working on that one now!
    0
  • Metro2
    That looks like it's related to the updated case I mentioned, CPANEL-37558. We're working on that one now!

    Doh! I normally check the links to cases when you post them, and I totally missed that one. Thanks for pointing it out! Small update on this - in case it hasn't already been noticed or discussed - while I cannot edit an individual MX TTL and Save, I CAN edit all 5 Google MX TTL's at once and then SAVE ALL successfully.
    0
  • Curious Too
    Was this ever resolved? I get this error when trying to edit a zone file after updating to cPanel 96.0.8: [2021-05-18 22:44:44 -0400] info [xml-api] API failure: Zone is invalid: Line 58: TTL set to prior TTL (3600) at /usr/local/cpanel/Cpanel/ZoneFile/LineEdit.pm line 390. [mass_edit_dns_zone] version [1].

    I fixed this issue by manually changing the top of the zone file from this: domain.com. 86400 IN SOA ns.nameserver.com. servers.domain.com. 2021072002 1200 7200 1209600 300 to this: domain.com. 86400 IN SOA ns.nameserver.com. servers.domain.com.com. ( 2021072201 ;Serial Number 3600 ;refresh 1800 ;retry 1209600 ;expire 86400 )
    0
  • wpinsites
    I hope this is helpful for anyone experiencing this issue. A provider for one of my clients was still having this happen on their systems which are running 96.0.13. We needed to make some zone changes - both add and modify - to reflect some hosting updates to the client's service and were getting that annoying generic error: "Error: The request failed. (Error ID: AAAAAA) Ask your hosting provider to research this error in cPanel & WHM"s main error log." While the host offered to make the changes for us, it didn't suit our situation so we persisted in looking for a workaround. After finding the tidbit above from @Metro2 we tried setting all of the A records to be the same using Metro2's method, but kept getting the same error. Strangely, we found that if we worked backwards from the txt records using the filter on the Zone Editor page, and ensure each type had the same TTL by editing them all at once, we were then able to adjust the A records in the same way, after which we were finally able to add new records. I trust the eventual fix for this will ensure that the TTL on all records of the same type are updated if the TTL is changed on a single record?
    0
  • cPRex Jurassic Moderator
    I trust the eventual fix for this will ensure that the TTL on all records of the same type are updated if the TTL is changed on a single record?

    No, that isn't what the fix will provide. Currently the interface is just having an issue reading TTLs in some circumstances, so the fix will allow that to work properly, but there's no reason that TTLs can't be different across different records.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post