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

[João Damas]

On 8 Feb 2010, at 11:40, Phil Regnauld wrote:

> João Damas (joao) writes:
>> 
>> The Fedora packages are acting as proxies for information they don't really care about
> 
>    That is a very pertinent observation.
> 
>> and without a mechanism for the original source to inform the consumer.
> 
>    Policy considerations aside:
> 
>    a) what policies exist in the OS distribution regarding "perishable"
>       data (maintenance, update), and what, if any, measures are implemented
>       to mitigate problems ?
> 
>    b) may the maintainer of the package take this decision alone ?
> 
>    ... the proper way to do this would be to split the keys/anchors out into
>    a separate file included from the main configuration, have that include
>    file as a separate package, and have automated updates refresh them as
>    needed -- the last point being a dialog in the installation ("would you
>    like to enable DLV/trust anchor package XYZ ? If so please note a cron
>    entry will be enabled reminding you when new keys are available, or enable
>    automated updates [...]").

or ship an RFC 5011 enabled DNS server? So use the OS shipped key to bootstrap then have the local software track the key into the future. Works better with a reduced number of SEPs (the software can cope with a lot of SEPs, but a larger number will increases the frequency of "events" and the administrators most probably can't cope or devote the necessary amount of time)

> 
>    Next step is how to communicate these suggestions out to the various
>    security and/or core teams of each distribution.
> 
>    Or, we don't care, and we sign the root (cf. Randy).
> 
>    Oh, wait, we DO need to update the root key once in a while!
> 
>    Reread from top ;)
> 
>> further down the > tree an even smaller part of the tree is signed, and of
>> that only a > small percentage has been able to link it's data to the parent zone.
> 
>    Yes.  But I do agree that a signed root is hard to ignore as an incentive.
> 

oh, yes. it is a great incentive. I all for it. However, during this initial period of multiple isolated islands, DLV is a welcome service.

>> Perhaps it could use a mechanism where a consumer could check that the real
>> source had been the one introducing the data, that there is a record
>> of the checks applied, rather than having to rely on a third party to
>> tell you they did (perhaps this is where, right now, the delegation of
>> trust to the DLV operators conveys some sense of authority).
> 
>    There are multiple options indeed.  Agreed.
> 
>> Overall, for duration of this period where the secure DNS tree is
>> highly fragmented, DLV does make a lot of sense. This does not
>> contradict the fact that a signed root is a significant step forward
>> and a very welcome one and, in this context, I will always trust
>> something I can trace from the root down more than something I get
>> from a third party.
> 
>    Isn't it how DLV works anyways ?
> 

Don't exactly know what you mean. DLV, the registry, talks directly to the source of the information and the resolver. DLV, the resolver algorithm, does try hard to find data in the usual DNS tree first.

Joao