I hope 96.0.10 also fixes AAAA-record; currently the DNS-manager does not submit the ipv6 and I wish the DNS zone manager would allow to add DS-records with algorithm 13. Cpanel can generate DSsec keys for that and sign its zone with that, but adding those record using the DNS zone manager is impossible (and I believe its just a matter of adding a few values to the dropbox).
@groentjuh - if you're seeing other issues outside of what case CPANEL-37035 covers it would be best to make a new thread about those.
There are 2 issues in this ticket. First one, the missing domain, has been fixed. The second one, mismatching TTL has been not.
Yes, and the customers are complaining.
Code:
Cpanel::Exception/(XID zt89hc) Zone is invalid: Line 38: TTL set to prior TTL (14400) at /usr/local/cpanel/Cpanel/ZoneFile/LineEdit.pm line 390.
==> cpsrvd 11.96.0.11 startedCpanel 96.0.11
I try to change TTL on NS records in WHM and get:
I try to change TTL on NS records in WHM and get:
Code:
Error: API failure: Zone is invalid: Line 12: TTL set to prior TTL (86400) at /usr/local/cpanel/Cpanel/ZoneFile/LineEdit.pm line 390.@MackSix - we have a separate case open for the TTL on NS records under CPANEL-37558. You can follow along with that here:
https://support.cpanel.net/hc/en-us/articles/4403227708823
https://support.cpanel.net/hc/en-us/articles/4403227708823
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?
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?
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.
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 )
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?
"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?
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.
