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

João Damas joao at bondis.org
Mon Feb 8 08:34:23 UTC 2010

On 7 Feb 2010, at 16:31, Shane Kerr wrote:

> Randy,
> On Fri, 2010-02-05 at 09:46 -0800, Randy Bush wrote:
>>> We have discovered that recent versions of the Fedora Linux distribution
>>> are shipping with a package called "dnssec-conf", which contains the
>>> RIPE NCC's DNSSEC trust anchors. This package is installed by default as
>>> a dependency of BIND, and it configures BIND to do DNSSEC validation.
>>> Unfortunately, the current version of this package (1.21) is outdated
>>> and contains old trust anchors.
>> what a great lesson
> I agree... but what is it? :)
> Sure, one lesson is "trust is tricky". Perhaps another is "get your
> trust as close to the source as possible", although that's doesn't
> always help.

trust is tricky and many other things, including dynamic (it changes between with time)
The key here is not whether there are 1, 42 or 666 trust anchors, it is whether you are getting them from the source or via proxies. The Fedora packages are acting as proxies for information they don't really care about and without a mechanism for the original source to inform the consumer.

I do agree that for the DNS, it would be good to have a single entry point to the secure tree and we are closer now than ever before, but the signature on the root is not going to be the end of multiple-key problem. The vast majority of TLDs are not signed, 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. Still a long way to go.

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, unlike in the Fedora packages for instance, and with clear rules to play. 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).

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.


More information about the dns-operations mailing list