One of the more irritating aspects of maintaining a DNS service is the need to notify parent services when changes are made. It’s annoying enough for nameserver records, which are relatively stable.
DNSSEC, on the other hand, if operated in accordance with best practice, involves the regular regeneration of keying material. That material then needs to be sent to the parent, so that it can update its own records accordingly.
While some services provide update APIs, these tend to be vendor-specific, and there is no shortage of services that require users to manually update/upload these changes via a membership portal.
The dnsoperator-to-rrr-protocol is a work item of the Registration Protocol Extensions (regext) IETF working group that addresses these problems, as well as others, by allowing a service operator to make these updates implicitly by way of DNS changes.
The process is bootstrapped by the client requesting a token from the parent service and placing that token into their own DNS zone, to demonstrate control. Once that has been done, the parent service takes CDS/CDNSKEY records from the child zone, constructs appropriate DS records based on those records, and places them in the corresponding parent zone. Future changes to DNSSEC state and NS records are then verified by way of DNSSEC, to ensure that the chain of trust is maintained.
There are many advantages to this approach, most of which follow from decreasing the maintenance burden:
- Third parties can operate and maintain DNS services on behalf of their clients without requiring that those clients either give them access to their parent service portal, or perform actions in that portal when requested.
- The key material used for DNSSEC is more likely to be kept fresh. Currently, there are APNIC Members that are still using keys that were originally generated in 2012.
- The protocol’s reliance on DNSSEC may help to increase DNSSEC uptake more generally.
APNIC staff are participating in this effort by writing test implementations of the protocol and investigating potential test deployment scenarios. If you would like to help with testing or similar, please let us know.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Greet idea