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

[João Damas]

On 9 Feb 2010, at 12:54, Chris Thompson wrote:

> 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? :-)

yes, though a different form of bad does not a good make :-)

> 
>> 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
> 

don't care about the incident in particular. The point is that the good part of DLV is the one where there is direct contact with the source.


>> 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.)

do they have direct contact with the source of the data? (RIPE and the source of the ITAR keys)

Joao