[dns-operations] Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories
joao at bondis.org
Tue Feb 9 12:15:57 UTC 2010
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... :-(
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
> 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)
More information about the dns-operations