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.

 

[cPRex]

Hey there! It sounds like you're experiencing case CPANEL-36573. We have a workaround posted here for the issue:

This system does not have a domain named domain.tld

and if you are signed in to our ticket system you can also "follow" that case for an update.

 

[Stacy HM]

Thank you. It works until we attempt to add a record, then get this:

Error: API failure: Zone is invalid: Line 28: TTL set to prior TTL (14400); Line 30: TTL set to prior TTL (14400) at /usr/local/cpanel/Cpanel/ZoneFile/LineEdit.pm line 390.

 

[cPRex]

Does that error happen independently of the "This system does not have a domain named “(domain)”" error?

 

[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].

 

[cPRex]

@Curious Too - I'm not seeing that error when I check a zone on my personal server that is also running 96.0.8. Can you run this command to verify that zone file and see if you also receive errors?

named-checkzone domain.com /var/named/domain.com.db

 

[MediaServe]

FWIW On 96.0.8 I'm experiencing the second error mentioned in this thread, (but not the original):

Error: API failure: Zone is invalid: Line 32: TTL set to prior TTL (14400) at /usr/local/cpanel/Cpanel/ZoneFile/LineEdit.pm line 390.

Running named-checkzone reports "OK".

There doesn't seem to be any relation to CPANEL-36573 as the affected domain is owned by a user, is properly mapped to the user in /etc/userdomains, and has the corresponding DNS line in /var/cpanel/users/[user]

 

[cPRex]

@MediaServe - could you get a ticket submitted so we can see this on an affected machine?

 

[MediaServe]

@MediaServe - could you get a ticket submitted so we can see this on an affected machine?

I've submitted ticket 94328705. While submitting it I found you've generated CPANEL-37035 for this, but I went ahead and completed the ticket anyway in case access to the server is helpful in diagnosing and resolving.

 

[cPRex]

Nice - just created the 19th, so I hadn't come across that one yet. Thanks!

 

[MediaServe]

Seems it's simply a matter of ensuring that all your DNS records share the same TTL value, (SOA and NS records excluded it seems). My client had everything set to 14400 with a google verification record set to 86400. Changing the TTL value of the google verification TXT record to 14400 allowed WHM to once again save records without error.

It's a bug of course, but easy enough to work around.

 

[cPRex]

Update - if you are signed into the ticket system you can check out the article on this and follow along here: cPanel

 

[cPanelFelipe]

Seems it's simply a matter of ensuring that all your DNS records share the same TTL value, (SOA and NS records excluded it seems). …

It's a bug of course, but easy enough to work around.

This is incorrect.

The problem happens when multiple records *IN THE SAME RECORD SET*—i.e., of the same name and type—have differing TTLs. Per RFC 2181/5.2, all records within a given set *must* share a common TTL.

So there’s no need for all records in a zone to share the same TTL.

This seems to be happening because the APIs behind the new zone editor are more stringent about this than the older APIs, but the zone editor itself doesn’t detect this issue early enough.

 

[smurf]

This seems to be happening because the APIs behind the new zone editor are more stringent about this than the older APIs, but the zone editor itself doesn’t detect this issue early enough.

We've just ran into the issue of creating a new DNS record conflicting with the existing DNS record TTL after updating to v96.

Are there plans to fix or relax the zone editor API? The error message is vague so it's causing a number of tickets and complaints.

 

[smurf]

We've performed some additional testing and the major issue is the zone editor now throws a 'generic' error message instead of a specific error.

E.g. Try and create a CNAME host record when an existing A host record for the same record exists in the DNS zone.

in v96 the error "Error: the request failed. (Error ID: Xxxx) Ask your hosting provider to research this error in cPanel & WHM's main error log.) is shown

in v94 the error "Error: autodiscover.example.com. already has an A record. You may not mix CNAME records with other records for the same name"

Unsure if this was better off split from the OPs issue and case but please can this be passed on so the error reporting can be fixed?

We're frankly disappointed this even passed testing to make it into a release version.

 

[cPRex]

@smurf - the issue will be resolved in the case in this thread's title. It still has not been assigned to a cPanel version just yet, but I'll be sure to post an update once that happens.

 

[AndyB78]

When trying to migrate MX to Google's, I've encountered the second problem in this thread because a TXT record had a 600 second TTL (different from the other TXTs with 14400). So I had to modify it to 14400, then add the Google MX records with 14400 instead of the 3600 specified by Google and then lower the TTL for the entire zone from WHM -> Set Zone TTL to 3600. I don't clearly understand if this is a bug or a strict implementation of a RFC but this feels like a bug. Any plans to fix this?

 

[cPRex]

@AndyB78 - our team is working on that, and as soon as I have an update I'll be sure to post!

 

[MajorLancelot]

Just ran into the same issue after the v96.0.9 upgrade on all machines:

[B]Error:[/B] API failure: Zone is invalid: Line 46: TTL set to prior TTL (14000) at /usr/local/cpanel/Cpanel/ZoneFile/LineEdit.pm line 390.

Can't add new, delete or edit existing records.

Running check-zone throws a clear pointer:

TTL mismatch in rrset

 

[MajorLancelot]

Deleting "google-site-verification" at both ends allows the records to be edited or added.