[CRISP-TEAM] draft proposal issue: reverse DNS

[Sweeting, John]

+1

On 12/15/14, 3:33 PM, "Alan Barrett" <apb at cequrux.com> wrote:

>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/t
>>ransition-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)
>
>_______________________________________________
>CRISP mailing list
>CRISP at nro.net
>https://www.nro.net/mailman/listinfo/crisp


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.