[dns-operations] Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories

[Chris Thompson]

On Feb 8 2010, João Damas wrote:

>On 8 Feb 2010, at 13:08, Randy Bush wrote:
>
>>> I will disagree with Randy that DLV provides "authority with no
>>> corresponding responsibility." DLV is merely a publishing mechanism
>>> where the data is controlled directly by the source
>> 
>> tehn why are there entries in the dlv when the cctld has specifically
>> asked them to be removed.
>
>I would say that was mistaken over-eagerness to be helpful.
>
>I have to come to think that was a mistake (that is just my personal opinion,
>as a user of the system) because it removes the source one step from the
>system, as the data is scooped from IANA's ITAR. 

"Scooping" is a less heinous act than "scraping", presumably? :-)

>That lead to the issue with the .pr TLD without any fault from .pr's side.

The problem would have arisen with anyone using the IANA ITAR entries
as trust anchors, if they were not fetching it often enough (and in this
case that meant "far more often than you might have guessed"). The IANA
were not (and still aren't) offering any guidance on refresh frequency
other than "regularly".

It's probably best to not to rehash the whole "find the culprit for the
.pr incident" thread. I could make a good case for partial fault at each
of NIC.PR, IANA and ISC. Or you could blame me for chivying NIC.PR into
joining the ITAR in the first place... :-(

https://lists.dns-oarc.net/pipermail/dns-operations/2009-April/003842.html

>Even if the data can be "trusted", as one can trust IANA to have done
>things properly, the one-step-removed nature of it is not good.

But anyone fetching the IANA ITAR and incorporating it into their
trust anchors already has a propagation delay.

ISC did increase the frequency that they fetched the IANA ITAR as a
result of the incident. They have a policy document at

https://www.isc.org/solutions/dlv/policy

that keeps me happy to use their DLV zone, both for validation and
publication. (Well, I *could* complain that it lists only the IANA
ITAR and RIPE-NCC TAR as imported TARs, while they have actually been
using the ARIN TAR as well since last July.)

>> as i said, authority with no corresponding responsibility
>
>nah, McCarthy is dead.

It's not even clear to me that it is (only) the .pr incident that
Randy is referring to. Be that as it may, publishing keys in the
IANA ITAR is a de facto solicitation for them to be *used*. (One
may also note that there are TLDs that are in dlv.isc.org but not
in the ITAR.)

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: cet1 at ucs.cam.ac.uk    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.