[ldns-users] Proposed new api to load build-time configured trust anchors
benno at NLnetLabs.nl
Tue Oct 18 06:22:28 UTC 2016
Thank you for your contribution. As you remarked, you didn't see any
feedback on your proposal. We should have informed you and the
ldns-users that for a number of developments we waited for openssl 1.1.0
(DANE TLSA support) and the release of getdns API 1.0 final release (a
number of ideas will also be implemented in ldns v2).
In the next month, we will start working on openssl 1.1.0 in ldns, open
tickets in bugzilla, and include or discuss patches submitted by
On 20/08/2016 19:15, Scott Shambarger wrote:
> I've been trying to get openssh to locally validate SSHFP records on OSX.
> The problem stems from the fact that OSX's configd rewrites
> /etc/resolv.conf each time the network changes (think connecting to a
> coffee shop's wifi). Openssh (configured with ldns) connections will
> then query the SSHFP record, but as the trust anchors are not referenced
> in resolv.conf, it is unable to perform DNSSEC validation.
> Openssh maintainers don't feel that trust-anchor loading is in their
> scope of responsibility, and feel the ldns interface should work "out of
> the box" (see Comment#1 at
> I submitted a patch to add a new api to libldns to load keys from
> build-time defined locations (by default $sysconfdir/trusted-key.key and
> $sysconfdir/unbound/root.key), in
> https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=727 -- however,
> there hasn't been any feedback on the proposal for 8 months...
> I added a new api as drill (and possibly other users) may want to load
> their own trust anchors and not have any loaded by default; however
> users such as openssh do want validation to work without adding their
> own anchor files.
> The root of the problem is still OSX, as other platforms can just add
> the "anchor" key to /etc/resolv.conf (but edits are wiped repeatedly on
> I'd love to hear if anyone has a better solution though :)
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
Benno J. Overeinder
More information about the ldns-users