RecordSet/Record API change

Registered by Betsy Luzader

The API for recordsets and records is too complicated. Currently, a user is forced to create a recordset before creating a record. This leads to a confusing user experience. This blueprint proposes to eliminate the record resource and only keep the recordset resource. Users will create, get, update and delete recordsets. When the user creates a recordset the code will determine if it should be a new recordset. If all data is the same except for the record, a Duplicate error will be returned and the user will then add the Record by modifying the Recordset. The record will no longer be accessible as a separate resource; only as part of the recordset. Please read the full specification for more information.

Background: The concept of a Resource Record Set is defined in [ RFC 2181, Section 5]. To summarize, it says, each DNS Resource Record (RR) has four parts: label, class, type and data. Any records that have all four equal, should be rejected as duplicates. However, it is possible for most record types to exist with the same label, class and type, but with different data. Such a group of records is defined to be a Resource Record Set (RRSet). A query for a specific label, class and type, should always return all records in the associated RRSet. It further states that all RRs in a RRSet should have the same ttl.

There will also be some database redesign work needed for this change.

Blueprint information

Betsy Luzader
Needs approval
Betsy Luzader
Series goal:
Accepted for juno
Milestone target:
milestone icon 2014.2
Started by
Betsy Luzader
Completed by
Betsy Luzader

Related branches



Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.


No subscribers.