[Bug 2119]=?UTF-8?Q?=20SSHFP=20with=20DNSSEC=20=E2=80=93=20no=20trust=20anchors=20given?=, validation always fails

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2119

--- Comment #4 from scott-mindrot at shambarger.net ---
(In reply to Damien Miller from comment #1)
> IMO this is for ldns to fix, otherwise every program that uses it
> would need to configure trust anchors and that seems a bit silly.

Replying to [comment:1 raimue@…]:
> I agree with the [https://bugzilla.mindrot.org/show_bug.cgi?id=2119#c1 upstream answer]. Was this ever reported to ldns upstream?

(I'm copying this from my comment on the macports openssh bug for
reference in this discussion)

I looked into submitting a patch to ldns upstream, and created a
working patch before realizing that I would break existing users of
libldns (for example, drill) if it was applied.

Basically, ldns_resolver_new_frm_file() loads policy from a file (as
the name suggests), one specifically documented to be /etc/resolv.conf
if the filename parameter is NULL (which is how it's currently called
from openssh).

drill uses this function if it's called without a server parameter, and
the use of /etc/resolv.conf may be overridden with the -c parameter 

If drill is run with a server, ldns_resolver_new() is used and no
default anchors are loaded -- and then only if in chase/trace mode, and
no other keys are yet loaded, it specifically loads
/etc/unbound/root.key as it's default.

Basically, drill expects to the ldns interface to allow all loaded keys
to be configurable at runtime, with no "magic policy" loading keys from
files that it can't override.  If I modified
ldns_resolver_new_frm_file() to load keys from, say,
/etc/trusted-key.key, then users of drill (and possibly other library
clients) couldn't control the keys they were using from parameters,
breaking use cases where specific keys need to be loaded (eg testing or
private roots).

I could, of course, submit a new interface to ldns that explicitly
loaded default keys from /etc/trusted-key.key (or some other default),
but then openssh couldn't use that interface until the new library
version was available on any particular distribution.

That leaves the final option, which is to use libldns the way drill
does, and load policy from the files explicitly specified... and at
least on OSX, we can't add that policy to the default file
(/etc/resolv.conf) because configd overwrites it.

I agree that having a general purpose "just resolve my hostname"
interface that loaded keys and policy from reasonable defaults might be
a useful interface for ldns to have, but we'd need to get that added,
and then we could use it when compiled against a recent enough version
-- in the meantime, the only way we can get a working ldns library on
OSX is to load the keys with ldns_resolver_push_dnssec_anchor(), and
"fixing" the existing ldns interface would really break current users
of it.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.