Warning: file_exists(): open_basedir restriction in effect. File(/srv/http/vhosts/aur.archlinux.org/public/web/locale//en/LC_MESSAGES/aurweb.mo) is not within the allowed path(s): (/srv/http/vhosts/aur-dev.archlinux.org/:/etc/aurweb/) in /srv/http/vhosts/aur-dev.archlinux.org/public/web/lib/streams.php on line 90
AUR (en) - luaunbound

Notice: Undefined variable: name in /srv/http/vhosts/aur-dev.archlinux.org/public/web/lib/pkgfuncs.inc.php on line 248

Package Details: luaunbound 2016.01.10-2

Git Clone URL: https://aur-dev.archlinux.org/luaunbound.git (read-only)
Package Base: luaunbound
Description: drop-in replacement for Prosodys internal DNS library with a binding to libunbound
Upstream URL: https://www.zash.se/luaunbound.html
Licenses: custom:MIT
Submitter: fordprefect
Maintainer: fordprefect
Last Packager: fordprefect
Votes: 0
Popularity: 0.000000
First Submitted: 2016-04-23 15:06
Last Updated: 2016-06-28 19:24

Dependencies (5)

Required by (1)

Sources (1)

Latest Comments

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 example.com. is signed and example.com. 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…

jhass commented on 2016-06-20 13:42

Unsetting LDFLAGS no longer works for me. Additionally unsetting CFLAGS works, but I think the cleaner approach is to patch Makefile to use CC:

diff -r f270a1cf86ce Makefile
--- a/Makefile Sun Jan 10 19:49:52 2016 +0100
+++ b/Makefile Mon Jun 20 15:34:28 2016 +0200
@@ -33,7 +33,7 @@
xsltproc root-anchors.xsl root-anchors.xml > $@

%.so: %.o
- $(LD) $(LDFLAGS) -o $@ $^ $(LDLIBS)
+ $(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS)

install -d $(DESTDIR)$(LUA_LIBDIR)/

Also there's no need to manually call squish.sh, the Makefile has a target for it, so both make all and make use_unbound.lua lunbound.so and make all works.

diff --git a/PKGBUILD b/PKGBUILD
index afbf8d9..cf599d8 100644
@@ -10,20 +10,20 @@ depends=("unbound")
makedepends=("mercurial" "unbound" "lua")
optdepends=("luajit: jit for lua")
+source=("${pkgname}::hg+https://code.zash.se/luaunbound" "use_cc.patch")
+ '6b11dfe9f5de743f101463fb3fb2144fe3aff75e7e19036f67d0e0b8adc8c36db73cf73d0aba483d651f8f5b2773093adc27e788354b165314c777e8de45bf28')

prepare() {
cd "$srcdir/$pkgname"
# fixed commit
hg checkout f270a1cf86ce
+ patch -p1 < "$srcdir/use_cc.patch"

build() {
cd "$srcdir/$pkgname"
- ./squish.sh > use_unbound.lua
- unset LDFLAGS
- make lunbound.so
+ make all

package() {