Package Details: luaunbound 1:0.5-1

Git Clone URL: (read-only, click to copy)
Package Base: luaunbound
Description: drop-in replacement for Prosodys internal DNS library with a binding to libunbound
Upstream URL:
Licenses: custom:MIT
Submitter: fordprefect
Maintainer: fordprefect
Last Packager: fordprefect
Votes: 0
Popularity: 0.000000
First Submitted: 2016-04-23 15:06
Last Updated: 2020-06-30 19:47

Latest Comments

1 2 Next › Last »

fordprefect commented on 2018-06-19 19:36

@moparisthebest: thanks, fixed.

moparisthebest commented on 2018-06-19 17:36

These are missing from makedepends, won't build without them: "libxslt" "ccache"

jhass commented on 2016-06-28 21:55

It seems to work that way for me, I don't know. This sort of things are quite hard to debug with out hands on the system ;)

fordprefect commented on 2016-06-28 21:53

my system is configured to use unbound in /etc/resolv.conf, thats definitely working (tested with dig +dnnsec). still luaunbound does not do its job for the prosody module and i was not able yet to figure out where it fails, so i thought i'd ask for your experience…

jhass commented on 2016-06-28 21:47

No, libunbound is a DNSSEC aware DNS resolver library, it is not in any way using using unbound local API or a unbound specific protocol. It is not at all coupled to a locally running unbound server. Unbound and libunbound are different projects, by the same people and probably sharing a bit code, but not dependent upon each other (well if anything unbound depends on libunbound, but certainly not the other way around).

If you do have a local unbound running, your system might simply not be configured (in /etc/resolv.conf) to use it.

Regarding Google DNS, to make downgrade attacks effective, you would need an active MITM with 100% success rate, as soon as you get mixed responses, for example com. saying is signed and saying it isn't, you'll get resolver failures and thus the MITM gets noticable. Of course however unlikely it is still a possibility and running a local recursor eliminates that issue.

fordprefect commented on 2016-06-28 21:39

as i understood it, luaunbound couples prosody to the running unbound instance. dnssec via google is not useful anyway (because you cant trust it other than local). but i didnt manage to make it work :/

jhass commented on 2016-06-28 21:37

Ah well, as I understood it libunbound is simply needed in order to preserve any DNSSEC related replies. It does not implement a full recursor inside. So you regular OS wide configured upstream resolver (/etc/resolv.conf) still needs to be DNSSEC aware. Google DNS would be, running a local unbound instance is another option.

fordprefect commented on 2016-06-28 20:56

i stumbled upon this in combination with prosody-mod-s2s-auth-dane, that requires dnssec (and uses luaunbound for that). after installing and (supposedly) enabling both auth-dane complained about not being able to do dnssec requests and fell back to non-dane-auth. thats how i came to think luaunbounds doesnt work for me.
maybe i remember something wrong, did this some time ago…

jhass commented on 2016-06-28 20:52

Well tbh. I didn't thoroughly verified yet, but it seems so. Do you have an easy way to verify? I can't spot any error related to it in the startup log anymore at least.

fordprefect commented on 2016-06-28 19:26

@jhass: thank you for your suggestions, just took them all in.
did you manage to make prosody use luaunbound? i failed so far, and zash (the developer) was not willing to help either…

edit: sorry for the delay, vacation time…