According the Doc: https://docs.openstack.org/ ID is a default key: Sorts the response by the this attribute value. Default is id. You can specify multiple pairs of sort key and sort direction query parameters. If you omit the sort direction in a pair, the API uses the natural sorting direction of the server attribute that is provided as the sort_key. Actually the default key used in code is “created_at” https://github.com/openstack/designate/blob/master/designate/sqlalchemy/base.py#L225
So after spending some time on the sort_key and its current default of 'created_at' versus documentation indicating 'id', here's what I think. Typically in database design the id is detained by an autoincrement-er unsigned int type value, there are a ton of reasons why this is done this way. Openstack used an UUID for the primary key, which is not wrong, but from a purely DB view it is not optimum, which is a long story. By using the UUID and ensuring its uniqueness each time a row is inserted into a table with this as the primary key there is no guarantee of the sort order. whereas an id of an auto-increment nature sort order is guaranteed by insert order. So changing the default sort_key or id from created_at causes a lot of tests to fail when trying to match against a sorted list, for example. In nove they default generally to 'created_at', because it guarantees the insert order. In Designate there is one place in the Doc, api-ref where the sort_key is mentioned, which is an easy change, whereas a code change is going to be messy, because it exposes a lot of test assumptions made on the ordering. IMHO, the insert order is critical versus the unknown predictability of the randomness of the UUID. Will meet with the author of this bug and PTL.
After conversations with QE we will be changing the api-ref documentation.
Closing this with "upstream" as the proposed fix is in the API reference which is an upstream only document.