[Feature Request] Add unique identifiers to RRsets in PowerDNS API responses

[amirzp]

Summary

PowerDNS API should provide unique identifiers for RRsets to enable better programmatic management and change tracking.

Current API Structure

PowerDNS currently returns RRsets without unique identifiers:

{
  "rrsets": [
    {
      "name": "example.com.",
      "type": "A",
      "records": [
        {
          "content": "1.1.1.1",
          "disabled": false
        }
      ]
    }
  ]
}

Problem

• RRsets lack unique identifiers
• Applications cannot reliably track which RRset has changed
• Difficult to perform precise updates or deletions on specific RRsets
• Change detection becomes unreliable when RRset content changes

Proposed Solution

Add a unique id field to each RRset:

{
  "rrsets": [
    {
      "id": "UUID",
      "name": "example.com.",
      "type": "A",
      "records": [
        {
          "content": "1.1.1.1",
          "disabled": false
        }
      ]
    }
  ]
}

[omoerbeek]

I think in a zone RRSets are uniquely identified by the composite key (name, type).

[hlindqvist]

• RRsets lack unique identifiers

• Applications cannot reliably track which RRset has changed

• Difficult to perform precise updates or deletions on specific RRsets

• Change detection becomes unreliable when RRset content changes

Is the intention that there would be some kind of versioning rather than just a different means of identifying which RRset it is? Or otherwise, how does the proposed id value change the outcome?

For instance, is this essentially part of some different take on #6247 when it comes to precise updates?

[amirzp]

I think in a zone RRSets are uniquely identified by the composite key (name, type).

You're absolutely right that (name, type) uniquely identifies RRSets within a zone.
However, there's a significant challenge when it comes to change detection.

Example: Type Change

Before:
www.example.com — A → 192.168.1.1

After:
www.example.com — CNAME → example.com

The Problem

With (name, type) as the identifier:
✅ We can identify the old RRset: (www.example.com, A)
✅ We can identify the new RRset: (www.example.com, CNAME)
❌ But we can’t tell that these represent the same logical record that simply changed its type
❌ As a result, we can’t track this as a single modification event — it looks like a deletion and a creation instead of an update

---

That’s why having a stable RRset ID would be valuable — it allows systems syncing or auditing DNS data to correlate logical changes more accurately.

[amirzp]

• RRsets lack unique identifiers
• Applications cannot reliably track which RRset has changed
• Difficult to perform precise updates or deletions on specific RRsets
• Change detection becomes unreliable when RRset content changes

Is the intention that there would be some kind of versioning rather than just a different means of identifying which RRset it is? Or otherwise, how does the proposed id value change the outcome?

For instance, is this essentially part of some different take on #6247 when it comes to precise updates?

Yes — the idea is indeed to introduce a form of versioning for RRSets.

[hlindqvist]

As a result, we can’t track this as a single modification event — it looks like a deletion and a creation instead of an update

In terms of RRsets, that is exactly what it is

[amirzp]

In terms of RRsets, that is exactly what it is

In that case, from what I understand, given this design, implementing a unique identifier wouldn’t be logical.

[Habbie]

Maybe you can use comments (which are per rrset) to put your unique ID in. Then if your API client is changing something from A to CNAME, it can move the ID with it.

[amirzp]

Maybe you can use comments (which are per rrset) to put your unique ID in. Then if your API client is changing something from A to CNAME, it can move the ID with it.

Thanks for the suggestion! We actually considered that approach before.
However, since multiple teams use this setup, implementing a common convention to store an ID inside the comment field — and ensuring everyone consistently follows it — would be quite challenging for us.

[kpfleming]

But we can’t tell that these represent the same logical record that simply changed its type

This is likely the only (or possibly one of two) case where that would be true; any other delete/add combination would not represent a 'change of type for a logical record'. If an A RRset is deleted and a TXT RRset is added, those would likely not qualify as a 'change of type' - and I can't think of any other combinations (other than A/AAAA + CNAME) which would.

[Miladbr]

I think in a zone RRSets are uniquely identified by the composite key (name, type).

PowerDNS follow a logically sound model based on RFC standard, but modern use cases require additional capabilities. A persistent ID for managing logical assets and tracking changes beyond basic type modifications has become a practical necessity, increasingly adopted by advanced APIs like Cloudflare's and automation tools.

[Habbie]

Do you have an example of an API model that better fits the use case here?