Hi Alfred, On 2010-12-01, at 08:06, Alfred HÎnes wrote:
> It is now going to be two weeks since the IANA ITAR has been > factually decommissioned, but still the last entry that has > been removed from the ITAR, the DS record for the ARPA. zone, > has not been placed into the root zone -- as confirmed by > today's TLD DNSSEC Report: > <http://stats.research.icann.org/dns/tld_report/> . > > Isn't that a shame, another discredit of bureaucracy ? > > I agree that the planned decommissionning was not an emergency, > but couldn't it be expected that, after the final date had been > published *four* weeks ago, the procedures for the ITAR and the > Root zone could have been reasonably coordinated? This seems slightly off-topic for an IETF working group, but no doubt there is an interested audience here so I'll take corresponding liberties. The situation with ARPA is, as you know, that it is signed and that its trust anchor has yet to be published in the signed root zone. This has been the case for quite some time, now (since long before any plans to end-of-life the ITAR were developed). Since the time at which a signed ARPA zone was first published there have been a number of ways for validators to acquire secure answers from it: (a) through manual configuration of an ARPA trust anchor (b) through automated configuration of an ARPA trust anchor, e.g. via the ITAR (c) using a trust anchor from secspider or other third-party DNSSEC monitors (d) by the use of DLV (e.g. DLV.ISC.ORG). Since the ITAR has been decommissioned, (b) above is no longer an option for new configurations (although depending on how you set things up, you might retain a trust anchor from a previous ITAR download). There was a window following the decommissioning of the ITAR in which ARPA.DLV.ISC.ORG disappeared. We fixed that once it was brought to our attention, on another public list. The long-term, steady-state solution for validating responses to queries in the APRA domain is a DS RRSet in the root zone, and until that happens some manual configuration is going to be required: explicit ARPA trust anchors, or implicit ARPA trust anchors via an explicit DLV.ISC.ORG trust anchor, etc. We have considered the need for manual configuration to be really quite independent of the operational state of the ITAR, which is why the ITAR decommissioning plan was not closely tied to the ongoing efforts relating to DNSSEC in ARPA. I appreciate that there is eagerness amongst the technical community to see a DS record in the root zone. Operationally, we are ready. I have no information on the expected time at which the root zone change processing for ARPA's DS RRSet will commence, but I'm happy to report back when I know more. To the best of my knowledge there is no political problem at this time, just paperwork. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
