[dnssec-deployment] Plans to sign arpa, in-addr.arpa, ip6.arpa?

Kevin Oberman oberman at es.net
Sat Nov 7 18:22:43 EST 2009

> From: Joe Abley <jabley at hopcount.ca>
> Date: Sun, 8 Nov 2009 07:32:47 +0900
> Hi Kevin,
> On 2009-11-08, at 07:18, Kevin Oberman wrote:
> > I'm not sure that rolling them into the root is a good idea, but I can
> > see good argument and reason to have the contents of in-addr.arpa and
> > ip6.arpa rolled into .arpa.
> What about the other existing delegations from ARPA, E164.ARPA,  
> IRIS.ARPA and URI.ARPA, or any future delegations?
> Are IN-ADDR.ARPA and IP6.ARPA special cases in your mind, or were you  
> imagining a blanket prohibition on delegations from the ARPA zone?
> There's a mechanism available to put forward such ideas, which you'll  
> find in RFC 3172.

I really don't like the term "blanket prohibition". It simply implies
setting something up so that there is a good excuse for not
thinking...sort of like "zero tolerance".

I think the issue is one that should depend on technical merit. Does the
cost of having a zone cut out-weigh the benefit? And, because having a
zone cut for one case does not mean that having one for every case is a
good thing. As long as the administration of the domains is common, the
issue should come down to whatever is easiest to maintain reliably.

My knowledge of the other .apra zones is quite limited, especially IRIS.

Obvious issues: How big is the zone? How often does the data change. How
many entities are going to have delegations from a zone. Probably
several I am not at all aware of as I have never handled anything like
.arpa. (Well, there was .de, but that was quite a few years ago and life
and DNS were much simpler.)

I don't think prohibition is a good thing. I do think that
consolidating multiple domains into a single zone should not be rejected
out of hand or mandated and, since all of .arpa (as far as I know) is
handled by ICANN, it probably should be a mostly internal issue, though
the impact on external entities like RIRs and local DNS admins should
be taken into consideration.
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

More information about the Dnssec-deployment mailing list