Support a zone record priority of 0 in `ZoneRecordAttributes`

[ggalmazor]

Description

A zone record priority of 0 cannot be sent through ZonesService.CreateRecord or ZonesService.UpdateRecord. ZoneRecordAttributes.Priority is a non-pointer int tagged omitempty, so the zero value is indistinguishable from an unset priority at serialization time, and it is dropped from the request body:

type ZoneRecordAttributes struct {
	ZoneID   string   `json:"zone_id,omitempty"`
	Type     string   `json:"type,omitempty"`
	Name     *string  `json:"name,omitempty"`
	Content  string   `json:"content,omitempty"`
	TTL      int      `json:"ttl,omitempty"`
	Priority int      `json:"priority,omitempty"`
	Regions  []string `json:"regions,omitempty"`
}

The type already documents this exact hazard, and resolves it for Name with a *string:

Compared to most other calls in this library, you should not use ZoneRecord as payload for record calls. This is because it can lead to side effects due to the inability of go to distinguish between a non-present string and an empty string. Name can be both, therefore a specific struct is required.

Priority has the same property. A priority of 0 is a valid MX priority, and several mail providers document it for their MX records, so the value is not exotic.

The consequence is silent. A caller that sets only Priority: 0 produces the 3-byte body {}, the API answers 200 OK, and the record keeps its previous priority. Nothing in the response tells the caller that the update was a no-op. This was reported downstream in dnsimple/cli#67, where the only workaround is to delete and recreate the record, which changes the record ID and removes the mail route of the Zone for a short time.

Reproduced with dnsimple 0.10.0, which depends on dnsimple-go v9.1.0:

$ dnsimple records update wonderland.test 10000001 --priority=0 --debug
2026/08/17 10:00:57 Request (https://api.dnsimple.com/v2/1234/zones/wonderland.test/records/10000001): &http.Request{Method:"PATCH", ... ContentLength:3, ...}
2026/08/17 10:00:57 Response: &http.Response{Status:"200 OK", ...}

The CLI is not the origin of the defect: it already forwards the flag whenever the user sets it, guarding on cmd.Flags().Changed("priority") rather than on the value.

Expected Behavior or Outcome

• A caller can set a zone record priority of 0 through CreateRecord and UpdateRecord.
• The serialized request body contains "priority": 0 when the caller explicitly sets the priority to 0.
• A caller that leaves the priority unset still produces a body with no priority key, so existing partial updates are unaffected.

Acceptance Criteria

• ZoneRecordAttributes can express "the priority is explicitly 0" distinctly from "the priority is not set".
• UpdateRecord sends "priority": 0 in the request body when the caller sets the priority to 0.
• CreateRecord sends "priority": 0 in the request body when the caller sets the priority to 0.
• Omitting the priority continues to produce a request body with no priority key.
• Tests assert the serialized payload for both the explicitly-zero case and the unset case.

Resources/References

• Reported downstream in The records update command does not set a priority of 0 cli#67
• DNSimple API, update a zone record: https://developer.dnsimple.com/v2/zones/records/#updateZoneRecord
• ZoneRecordAttributes: https://github.com/dnsimple/dnsimple-go/blob/v9.1.0/dnsimple/zones_records.go#L29-L37

Notes

Changing Priority to a *int mirrors the treatment Name already receives and keeps the fix local to this type. However, it is a breaking change for callers that assign the field directly, so it belongs in the next major release.

Alternatively, we could keep the field an int and drop omitempty, which would send "priority": 0 on every request. However, that would turn every partial update into one that also resets the priority, so it is not a viable option.

TTL carries the same ambiguity. A TTL of 0 is not a valid value for the API, so the defect is not observable there today, and this ticket is scoped to Priority.