A few metadata funnies in the API

[james-stevens]

• Program: Authoritative
• Issue type: Bug report

All this refers to the REST/API.

• Since 4.6.X SOA-EDIT can now be addressed as either the zone property soa_edit OR the metadata item SOA-EDIT. When addressed as a metadata item you can assign it multiple values, but clearly it should only ever have one value, or no value. The first item in the metadata list is the one that appears when asking for the zone property soa_edit.

• When addressed as the zone property soa_edit you can't delete its value, only set it to an empty string & its not clear if this will mean the server will fall back to using the system/conf default or not. You can delete it when addressing it as the metadata item SOA-EDIT

• SOA-EDIT-API can only be addressed as the zone property soa_edit_api & its value can not be deleted, only set to blank. When other zone properties are set to blank, this causes the corresponding metadata item to get deleted, but not for soa_edit_api or soa_edit.

• There are various metadata items, for example those that have boolean values, that can be given multiple values, but clearly should not. This also applies to all the SOA-EDIT* items, for example. Having an item both true and false is very quantum mechanics, but probably not anybody wants.

• Although SOA-EDIT can now be addressed as a metadata item, other metadata items that are faked to appear as if they are zone properties are not allowed to addressed as the metadata they really are: SOA-EDIT-API, NSEC3PARAM, TSIG-ALLOW-AXFR & AXFR-MASTER-TSIG

Environment

• Operating system: Alpine v3.16
• Software version: 4.6.2
• Software source: Alpine Repo / Alpine Community Repo

Other information

PERSONALLY, I think you should drop the whole "zone properties" charade, as only kind & the zone name are real zone properties, the rest are all implemented (in the database) as metadata values - therefore users SHOULD be allowed to address them, in the API, as the metadata they really are - instead you give the error message "Not a metadata item" when that's exactly that they really are !?!?!?!?

[zeha]

The "charade" as you describe it was built to avoid exactly the problems you describe. I.e. there is no point of assigning multiple values to SOA-EDIT, SOA-EDIT-API, etc., and the facade is intended to allow only valid settings. IIRC at some point this got relaxed, and now some metadata is visible as metadata and via the facade, leading to new problems.

[james-stevens]

But the protection you describe only works via the API - i.e. the protection can still be violated by direct SQL changes to METADATA

However, if the user is only updating the METADATA via the API, then all the protection you describe can still be applied via the METADATA update calls.

So I don't really buy this argument.

[zeha]

But the protection you describe only works via the API - i.e. the protection can still be violated by direct SQL changes to METADATA

Sure, but this is also true if you use a hex editor on your database files.

However, if the user is only updating the METADATA via the API, then all the protection you describe can still be applied via the METADATA update calls.

That makes for a very weird API.

[james-stevens]

That makes for a very weird API

That ship already sailed - with some METADATA addressed as real METADATA and some as fake zone properties, as well as having some real zone properties.

RRs are validated when submitted via the API - I don't see how validating METADATA is any different.

In fact I'd say it's weird that you DON'T validate API submitted METADATA.

Are you really trying to argue that validating METADATA value, when submitted via the API, would be a bad idea? Its a case to be made, but not one I would support.

IMHO, having all METADATA treated as METADATA, and correctly validated, would be a simplification of what you currently have.