Zone Ownership and API Permissions

I've been working on a dynamic DNS script that would work with DynDNS, dnsomatic, and similar updaters.

I'm trying to understand zone ownership, and how it plays into API token permissions. When I first started with this script, things went well and aside from the script issues alone, things went without a problem. When I created the zone "remote.domain.com" I didn't want it linked to the account "domain.com" as I wanted it to persist. I created the zone, and did not associated it with an account. I created an API token with the following permissions:

Manage DNS Records manage-dns-records
Edit DNS Zones edit-dns

My script was working fine for a day an a half. But after some account deletions and additions, I noticed the script was no longer working correctly. I could list the domains, see the records in the zone, etc. but I could no longer edit the zone record and was getting a {"status":0,"statusmsg":"Permission Denied"} message from the API. After some investigation, I deleted the "remote.domain.com" zone, recreated it, and assigned it to the "domain.com" account. Magically, the updates were working again.

After looking into it a bit more, I noticed that if you do not assign a zone to an account, you get the message "Zone is owned by system" which seems to interact with the API differently than if you assign the zone to an account.

Is there some aspect of zone or API permissions that I'm missing perhaps? What are the implications to a zone being "owned by system"?

 

For example, if you click to edit a zone created by the setup wizard, say the server hostname zone or NS zones, then I believe they show as owned by system, and they do not have mail server configuration (local or remote or auto, etc.). If you manually create a zone and don't assign it to a user, like the server hostname for a DNS only server and don't assign it to an account, then it will be owned by system, and shoe the mail server configuration at the bottom. I ran into this because I had initially created a new zone for dynamic DNS, and didn't want it associated with an account, so it would persist outside of the account should the account itself be deleted. All of this said, I changed my approach, and now use account zone records for dynamic DNS.

Are there only two owners of a zone then? Use owned or system (root?) Owned?

 

Would it then make sense to perhaps restrict this or provide more info on the page? Noobs like me could use the help in those situations.

 

Well, there are a couple things...

1) Maybe System could be in the "user" list, and be the default selection, the same way the current default of no selection results in the record being assigned to System. This consciously forces the user to default to System, or select an actual user and eliminates ambiguity for a new user of cPanel in particular.

2) Perhaps some improvement in consistency to the way System zones are created. This is perhaps more nit-picky than practical. When cPanel setup creates the A and NS records for the server host, if you go back to edit them after, there are no mail configuration details (Auto, Local, Remote, etc) at the bottom. However, if I as root manually create a System record, those configuration elements are included at the bottom. It seems that when cPanel setup creates the records, it uses a slightly different method which doesn't produce those configuration options. If I'm misinterpreting something, then perhaps this could be explained.

System record with email config (i.e. manual zone add)


System record without email config (i.e. cPanel setup)