Regional Internet Registries (RIRs) are the organizations responsible for the global management and delegation of IP addresses (IPv4 and IPv6) and Autonomous Numbers (ASN). There are five RIRs worldwide, each serving a specific region. The RIR for Latin America is LACNIC, with its headquarters in Montevideo, Uruguay. Likewise, APNIC is the RIR for Asia Pacific, AFRINIC for Africa, RIPE for Europe, and ARIN for North America.
Among other tasks, each RIR maintains the DNS sub-tree for the reverse resolution of the IP addresses delegated to a given resource holder. For example, if NIC Chile receives from LACNIC the IPv4 prefix 200.7.7.0/24, its reverse DNS names must be maintained under 7.7.200.in-addr.arpa, a child of parent zone 200.in-addr.arpa managed by LACNIC. Thus, each recipient of an IP prefix assigned by LACNIC may request the delegation of their segment.
To do so, LACNIC provides a control panel where each organization can declare its nameservers (NS) and thus obtain a delegation entry in the DNS.
The problem with inter-RIR transfers
So far so good. But what happens when a LACNIC member organization sub-delegates part of the resources it has been assigned to an organization that wishes to register with another RIR? This is known as an “inter-RIR transfer.” It happens when, for example, a European organization with a shortage of IPv4 addresses and a Latin American organization with unused address space enter an agreement for the transfer of an IPv4 block. In this case, both the entity that transfers out a block and the organization receiving the transfer go to LACNIC and to RIPE to register the transfer and update the WHOIS information, geolocation, and — most importantly — the administration of the reverse resolution of the block to be transferred, which, once the transfer is complete, will appear in the RIPE user panel of the new organization, and will no longer appear in the LACNIC panel.
(Free access, no subscription required)
However, a problem that arises is precisely how to properly delegate reverse resolution of the resource in the DNS.
In a case such as the one described in the example above, the new assignee will define in RIPE the nameservers to which it wishes to delegate the segment, but that DNS sub-tree does not belong to RIPE but to LACNIC, so some type of coordination is needed to communicate the data.
Zonelets
However, a problem that arises is precisely how to properly delegate reverse resolution of the resource in the DNS.
In a case such as the one described in the example above, the new assignee will define in RIPE the nameservers to which it wishes to delegate the segment, but that DNS sub-tree does not belong to RIPE but to LACNIC, so some type of coordination is needed to communicate the data.
Zonelets
For these cases, the mechanism defined by the RIRs was the use of “zonelets,” which are pieces of DNS configuration files that each RIR communicates to the RIR corresponding to the reverse delegation of the resource, using an automated mechanism that shares this information on a daily basis.
In our example, when this organization defines its NSs in RIPE, RIPE builds a zonelet with this data, places it in a private repository shared among the different RIRs, and LACNIC fetches this block of configuration and places it on the corresponding reverse tree. The DNS query that originates in in-addr.arpa is then delegated to the prefix controlled by LACNIC, moves down the tree, and is finally delegated to the end customer’s NS.
The problem with zonelets
Despite some sporadic problems due to system maintenance issues and the difficulty of monitoring the zonelet systems, this mechanism has worked well for years. While these have been improved over time, the system still suffers from a problem that is more intrinsic to the solution, namely, the time it takes for a change to be carried over to the DNS. A zonelet-style mechanism requires batch processing and checks that are not necessarily fast enough.
On the other hand, given the current reality of IPv4 exhaustion, inter-RIR transfers are expected to become increasingly frequent, subjecting the system to greater stresses.
This is why our proposal is to modify the re-delegation mechanism with a relatively new technique in DNS that simplifies the process, leaving everything within the normal DNS protocol: the use of DNAMEs.
What is DNAME
DNAME is a DNS extension technique originally defined in 1999 and updated in 2012 in RFC6672 that defines a record that allows a complete sub-tree to be delegated to another DNS node. The name refers to the famous CNAME record (an abbreviation that stands for “canonical name”), which maps an alias to an “end node” of the DNS tree. DNAME does this for an entire branch.
How to use DNAME for reverse mappings
In our example, the only thing that LACNIC should do when transferring one of its resources to another RIR is to define a DNAME record pointing to an “alias” in the destination RIR, which can, in turn, redefine NSs for names lower in the hierarchy.
This alias should be a space under the control of the destination RIR that must be previously agreed upon. As an example, we will use in-addr.delegated.<RIR SPACE>.
In this way, any change to the NSs of the organization controlling the prefix is done directly at RIPE, which in turn modifies it under the in-addr.delegated.ripe.net tree directly under its control without further involving LACNIC, the former RIR.
The resource holder must also take care to change the name of its end zone to respect the new subtree under the control of its RIR, and not directly in-addr.arpa as usual.
The changes to the procedure would be as follows:
The RIR that is giving up a resource must add a DNAME in place of the zone-cut, pointing to a new name that is under the control of the RIR receiving the resource.
The RIR receiving the resource includes the NS of the end customer in this new name.
The end customer becomes authoritative for that new name within the space of the RIR receiving the resource.
If a transfer needs to be canceled or rolled back, the only action required is to remove the DNAME record and return to the original normal delegation, with the NS of the original customer.
The procedure is the same in the case of “deep” delegations. If a parent delegates directly to a grandchild without referring to the child (empty-non-terminal), that is where the NSs are replaced by the DNAME record pointing to the “receiving” DNS tree.
Analysis of the solution
A lab prototype of this solution was created, its operation was validated, and tests were conducted using different measurement platforms and DNS resolution software.
We believe that this architecture can be coordinated between the RIRs and replace the current zonelet mechanism. Improvements include:
A simpler solution as a concept, using DNS standards.
No longer depending on ad-hoc solutions subject to other types of failures and moving to a solution within the DNS.
Greater control over the end customer, who once again has authoritative control of the zone using the DNS protocol.
Changes are instantly propagated according to normal DNS timings.
Of course, there are certain considerations that must be taken into account, such as changes in the coordination between the different RIRs. However, we believe that these considerations are less than those that exist today and can therefore be implemented with proper planning and internal coordination.
Another thing to consider is the configuration that needs to be changed by the end customer, who will now need to add a tag in the parent, <rir> .in-addr.arpa.
Finally, it is important to consider the records’ TTL. The growth of the resolution chain may lead to timeouts, so it is important to optimize the use of the cache.
As for the solution itself, experiments show that a 1.1% increase in the failure rate might be expected when using the technique described in this document, a result of legacy resolvers that are unable to follow the DNAME record. However, one might venture that such failures would be caused by very old or poorly configured resolvers, or within networks with excessive filtering. This failure rate might be considered acceptable in such a diverse environment as the Internet, where it is virtually impossible to expect a zero-error rate. In any case, the RIRs themselves can carry out tests closer to the real world, using “canary” delegations within the real tree and other success metrics.
With this project, NIC Chile seeks to support the community and provide a technique that will help improve the user experience of everyone involved, as well as its analysis.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.
