[CRISP-TEAM] draft proposal issue: reverse DNS

[Alan Barrett]

On Mon, 15 Dec 2014, Andrei Robachevsky wrote:
>> One issue I did not see discussed yet is around .arpa - I 
>> recall the NRO EC suggested the CRISP team appoints a liaison 
>> to the IETF to ensure that the proposal from IETF meets the 
>> numbering's community's expectations as far as .arpa is 
>> concerned.
>
> Before discussing a specific solution, I'd like to better 
> understand the relationships between the parties involved, which 
> in this context are not entirely clear to me.

My understanding is that the IETF (through the IAB) asserts 
control of the .ARPA top level domain, and instructs the IANA on 
what to do with portions of the name space; see RFC 3172.

The mapping between IPv4 addresses and *.IN-ADDR.ARPA domains is 
described in RFC 1034.  Delegation of portions of the name space 
to RIRs or end users is described in RFC 2050.  RFC 3172 section 3 
also says "Sub-delegations within this hierarchy are undertaken in 
accordance with the IANA's address allocation practices."

The mapping between IPv6 addresses and *.IP6.ARPA domains is 
described in RFC 2874, and RFC 3152 requests IANA to sub-delegate 
portions of IP6.ARPA to regional internet registries.  RFC 3172 
section 3 also says "names within this zone further delegated to 
the regional IP registries in accordance with the delegation of 
IPv6 address space to those registries."

> As I see this, the domains in question: ip6.arpa and 
> in-addr.arpa are delegated to IANA by the IETF (RFC3172, 
> RFC3152). The IETF also defined the policy. E.g. for 
> ip6.arpa: "Names within this zone are to be further delegated 
> to the regional IP registries in accordance with the delegation 
> of IPv6 address space to those registries. The names allocated 
> should be hierarchic in accordance with the address space 
> assignment."
>
> The administration of these domains is "a technical work 
> item per the existing ICANN/IETF MOU (RFC2860)" (see 
> https://www.iab.org/documents/correspondence-reports-documents/docs2010/transition-of-in-addr-arpa-generation/), 
> so strictly speaking the performance of this function is under 
> the *IETF* purview (although I am not sure if/what SLAs are 
> defined for this).

Yes, I think that's right.

> Now, if one looks at this from the perspective of the NTIA 
> contract, the administration of these domains and delegations 
> is out of scope. Add to this that these sub-registries are not 
> mentioned in the IETF response either.
>
> Perhaps a good way forward would be to leave this issue outside 
> this particular project altogether. The only problem is that the 
> RIRs will probably need to draft a contract with the SLAs and 
> this is one of the "IETF IANA" (but not "NTIA IANA") services 
> they are getting, so it will have to be addressed.

If the IETF chose not to mention this issue, that's all the more 
reason for us to address it.

I think that we should mention the mapping between IPv4 or IPv6 
addresses and corresponding domain names in in-addr.arpa or 
ip6.arpa, refer to the RFCs that say delegation of the sub-domain 
name space should follow allocation/assignment/delegation of the 
addresses, and say that the IANA operator should delegate domain 
names to RIRs (or end users).  Any SLA between the RIRs and the 
IANA operator should also deal with this issue.

> This issue is somewhat related to the shared management 
> of the top IP address registry (see my mail "draft 
> proposal: overlaps"). So I am thinking of the AoC mentioned in 
> ARIN's draft proposal between the RIRs and the IETF. Perhaps an 
> even better form would be an MoU that will take the spirit of 
> the proposed AoC and the substance related to this particular 
> service (+ the management of the shared registry), but IANAL ;)

An affirmation of commitments between the RIRs (or the NRO) and the 
IETF seems reasonable.

--apb (Alan Barrett)