#49007: openssh @6.9p1 +ldns SSHFP DNSSEC validation fails -------------------------------+-------------------------------- Reporter: scott-macports@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: openssh ldns | -------------------------------+-------------------------------- Changes (by raimue@…): * cc: marius.rieder@… (added) Comment: Adding maintainer of ldns to Cc. -- Ticket URL: <https://trac.macports.org/ticket/49007#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X

#49007: openssh @7.1p1 +ldns SSHFP DNSSEC validation fails -------------------------------+---------------------- Reporter: scott-macports@… | Owner: ionic@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: openssh ldns | -------------------------------+---------------------- Comment (by scott-macports@…): 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?

(sorry I didn't answer earlier, been busy with other projects :) 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 (as a new api, it can't really be backported as fix to distributions using the current or older libraries), preventing a working openssh + ldns on those systems for some time... That leaves the final option, which is to use libldns the way drill does, and load policy from the files explicitly specified... and we're back to not being able to modify the default (/etc/resolv.conf) because OSX won't let us. 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() I'll submit this analysis to the upstream openssh bug, but again OSX is hit harder than other platforms at the moment as we can't modify the /etc/resolv.conf config file to add a trust anchor, so we need a fix for that. -- Ticket URL: <https://trac.macports.org/ticket/49007#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X

#49007: openssh @7.1p1 +ldns SSHFP DNSSEC validation fails -------------------------------+---------------------- Reporter: scott-macports@… | Owner: ionic@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch Port: openssh ldns | -------------------------------+---------------------- Comment (by scott-macports@…): FYI: I created a new function to load root keys from a "canonical" location for the ldns library, and submitted to upstream as an enhancement request: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=727 Hopefully, if it (or something like it) is accepted, we can backport the patch to macports' ldns, and then submit a patch to call it from openssh. (I've created the openssh patch too, and it works well, but there's no point submitting it until there's a library to test it against :) -- Ticket URL: <https://trac.macports.org/ticket/49007#comment:6> MacPorts <https://www.macports.org/> Ports system for OS X