Re: UPDATE: Unbound - Add dns64 FLAVOR
On 2013/04/12 10:10, Todd T. Fries wrote: > -1. If the alternatives are worse, this seems useful. > > Seriously, the alternative is totd, which does not handle tcp, is fragile, > crashes frequently, and is unmaintained code. The alternative is the production DNS64 code in ports/net/isc-bind.
Re: UPDATE: Unbound - Add dns64 FLAVOR
Penned by Jakob Schlyter on 20130412 4:11.22, we have: | On 11 apr 2013, at 23:56, Ted Unangst wrote: | | > On Thu, Apr 11, 2013 at 14:57, Brad Smith wrote: | >> The following diff adds a dns64 FLAVOR to the Unbound port to integrate the | >> DNS64 support as provided by the Ecdysis project. | >> | >> Caveat.. do not run with the malloc flags J or U and thus also S. | >> This seems to expose bugs in the new code. | >> | >> Anyone who would be better at tracking down such bugs interested | >> in trying to find the root cause and fix them? | > | > It's not really my concern, but I am not too excited by the prospect | > of introudcing software that has known memory corruption bugs. | > Especially not a network server. We've disabled or removed ports for | > less obvious security problems. | | +1. If the patch is not good enough for Wouter (NLNetLabs) to include in the distribution, I'm reluctant to include it in the port. | | | jakob | -1. If the alternatives are worse, this seems useful. Seriously, the alternative is totd, which does not handle tcp, is fragile, crashes frequently, and is unmaintained code. unbound + dns64 is what I've been using at home for 6 months or so now, and I have to say the supposed issues with it are nonexistent compared to the weekly or more frequently restart / exit of totd and frustrations due to not handling tcp. Yes I have on my list to look at the code and see if I can do any damage in the bugfix department, with a perfectly functional system as is, and being in near survival mode in other ares, I suspect someone else will get to it before me. My $.02. -- Todd Fries .. t...@fries.net |\ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC\ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com\ 1.866.792.3418 (FAX) | PO Box 16169, Oklahoma City, OK 73113 \ sip:freedae...@ekiga.net | "..in support of free software solutions." \ sip:4052279...@ekiga.net \ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: UPDATE: Unbound - Add dns64 FLAVOR
On 11 apr 2013, at 23:56, Ted Unangst wrote: > On Thu, Apr 11, 2013 at 14:57, Brad Smith wrote: >> The following diff adds a dns64 FLAVOR to the Unbound port to integrate the >> DNS64 support as provided by the Ecdysis project. >> >> Caveat.. do not run with the malloc flags J or U and thus also S. >> This seems to expose bugs in the new code. >> >> Anyone who would be better at tracking down such bugs interested >> in trying to find the root cause and fix them? > > It's not really my concern, but I am not too excited by the prospect > of introudcing software that has known memory corruption bugs. > Especially not a network server. We've disabled or removed ports for > less obvious security problems. +1. If the patch is not good enough for Wouter (NLNetLabs) to include in the distribution, I'm reluctant to include it in the port. jakob
Re: UPDATE: Unbound - Add dns64 FLAVOR
On Thu, Apr 11, 2013 at 14:57, Brad Smith wrote: > The following diff adds a dns64 FLAVOR to the Unbound port to integrate the > DNS64 support as provided by the Ecdysis project. > > Caveat.. do not run with the malloc flags J or U and thus also S. > This seems to expose bugs in the new code. > > Anyone who would be better at tracking down such bugs interested > in trying to find the root cause and fix them? It's not really my concern, but I am not too excited by the prospect of introudcing software that has known memory corruption bugs. Especially not a network server. We've disabled or removed ports for less obvious security problems.
Re: UPDATE: Unbound - Add dns64 FLAVOR
On Thu, Apr 11, 2013 at 08:32:44PM +0100, Stuart Henderson wrote:
> On 2013/04/11 14:57, Brad Smith wrote:
> > The following diff adds a dns64 FLAVOR to the Unbound port to integrate the
> > DNS64 support as provided by the Ecdysis project.
> >
> > Caveat.. do not run with the malloc flags J or U and thus also S.
> > This seems to expose bugs in the new code.
> >
> > Anyone who would be better at tracking down such bugs interested
> > in trying to find the root cause and fix them?
> >
> > I noticed a similar diff was posted back in 2011 for Unbound
> > 1.4.9 but it never actually went in.
>
> It would be much better to get this upstream though - but there
> has been very little interest on unbound-users, I've asked people
> before to comment there so they can see that there is interest
> but nothing...upstream certainly aren't averse to it:
Well it isn't as if I am denying that. That much is obvious.
But it has not happened and most likely won't for some time,
especially with bugs that need fixing. Having it in ports at
least as a flavor at least allows for further testing and
feedback. If anyone is interested and able to fix any bugs
that are known or are found and we can roll them back in
then I think it is worth it.
> http://marc.info/?l=unbound-users&m=130553190330861&w=2
> "The patch is to be merged if good quality and useful for general
> audience. So I do not know. The source contrib directory in the
> tarball of unbound is useful for putting the patch meanwhile.
> ... [snip] ... I have simply not received patch(es) to put into
> the unbound contrib"
>
> but there are known problems,
>
> http://marc.info/?l=unbound-users&m=130530426030770&w=2
> Mostly portability (which would be better if it was in-tree), but also
> some SERVFAIL situations. For example for IPv6 reverse lookups OUTSIDE
> of the NAT64 prefix (so for your native path). The code synthesizes PTRs
> for the NAT64 prefix, I guess it is broken at this point. I'm going to
> report that, but the slow release cycles of ecdysis makes it annoying."
>
> and sperreault's last post there mentioned that things needed re-checking.
>
> > OK?
>
> I guess having it in the port for now wouldn't hurt. But there are a
> couple of things we should do. Firstly make it clear in DESCR that it is
> experimental and that there are known problems. Secondly, the current
> patch is difficult to maintain if upstream make any changes to the
> config parser, I would rather remove the patches for the following
> files:
>
> configlexer.c configparser.c configparser.h
>
> and just rm them:
>
> post-extract:
> cd ${WRKSRC}/util && rm configlexer.c configparser.c configparser.h
>
> they will be regenerated automatically at build time (flex in base is
> OK for this; src/usr.sbin/unbound does the same).
>
> (TBH if anyone is spending time hacking on unbound, rather than fixing up
> this patchset, it would be more useful to work out how to rip out the port
> allocator and just use the OS port allocator instead, ideally in a way
> which is controlled by a build or config option so it can be fed back
> upstream, afaik that is the main obstacle to enabling unbound in base...)
An updated diff.
Index: Makefile
===
RCS file: /home/cvs/ports/net/unbound/Makefile,v
retrieving revision 1.50
diff -u -p -r1.50 Makefile
--- Makefile24 Mar 2013 21:33:24 - 1.50
+++ Makefile11 Apr 2013 20:48:08 -
@@ -3,9 +3,11 @@
COMMENT= validating DNS resolver
DISTNAME= unbound-1.4.20
+REVISION= 0
CATEGORIES=net
MASTER_SITES= http://www.unbound.net/downloads/
+MASTER_SITES0= http://comstyle.com/source/
HOMEPAGE= http://www.unbound.net/
MAINTAINER= Jakob Schlyter
@@ -33,6 +35,19 @@ CONFIGURE_ARGS+= --enable-allsymbols \
--with-pidfile=/var/unbound/var/run/unbound.pid \
--with-conf-file=/var/unbound/etc/unbound.conf \
--with-username=_unbound
+
+FLAVORS= dns64
+FLAVOR?=
+
+.if ${FLAVOR:Mdns64}
+PATCHFILES=unbound-1.4.20-dns64.diff.bz2:0
+PATCH_DIST_STRIP= -p1
+
+post-extract:
+ cd ${WRKSRC}/util && rm configlexer.c configparser.c configparser.h
+.endif
+
+SUPDISTFILES= unbound-1.4.20-dns64.diff.bz2:0
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/unbound
Index: distinfo
===
RCS file: /home/cvs/ports/net/unbound/distinfo,v
retrieving revision 1.30
diff -u -p -r1.30 distinfo
--- distinfo24 Mar 2013 21:33:24 - 1.30
+++ distinfo11 Apr 2013 20:07:38 -
@@ -1,2 +1,4 @@
+SHA256 (unbound-1.4.20-dns64.diff.bz2) =
5Q5CAZ0GznImkN87jpTlD1DhEvTKvSNOOtcp1ABCFzk=
SHA256 (unbound-1.4.20.tar.gz) = FFJwAjB4c+VXNIpNdrYqwDaTfZwwM2EKhCUBjDeftW4=
+SIZE (unbound-1.4.20-dns64.diff.bz2) = 11404
SIZE (unbound-1.4.20.tar.gz) = 3613963
Index: pkg/DESCR
==
Re: UPDATE: Unbound - Add dns64 FLAVOR
On 2013/04/11 14:57, Brad Smith wrote:
> The following diff adds a dns64 FLAVOR to the Unbound port to integrate the
> DNS64 support as provided by the Ecdysis project.
>
> Caveat.. do not run with the malloc flags J or U and thus also S.
> This seems to expose bugs in the new code.
>
> Anyone who would be better at tracking down such bugs interested
> in trying to find the root cause and fix them?
>
> I noticed a similar diff was posted back in 2011 for Unbound
> 1.4.9 but it never actually went in.
It would be much better to get this upstream though - but there
has been very little interest on unbound-users, I've asked people
before to comment there so they can see that there is interest
but nothing...upstream certainly aren't averse to it:
http://marc.info/?l=unbound-users&m=130553190330861&w=2
"The patch is to be merged if good quality and useful for general
audience. So I do not know. The source contrib directory in the
tarball of unbound is useful for putting the patch meanwhile.
... [snip] ... I have simply not received patch(es) to put into
the unbound contrib"
but there are known problems,
http://marc.info/?l=unbound-users&m=130530426030770&w=2
Mostly portability (which would be better if it was in-tree), but also
some SERVFAIL situations. For example for IPv6 reverse lookups OUTSIDE
of the NAT64 prefix (so for your native path). The code synthesizes PTRs
for the NAT64 prefix, I guess it is broken at this point. I'm going to
report that, but the slow release cycles of ecdysis makes it annoying."
and sperreault's last post there mentioned that things needed re-checking.
> OK?
I guess having it in the port for now wouldn't hurt. But there are a
couple of things we should do. Firstly make it clear in DESCR that it is
experimental and that there are known problems. Secondly, the current
patch is difficult to maintain if upstream make any changes to the
config parser, I would rather remove the patches for the following
files:
configlexer.c configparser.c configparser.h
and just rm them:
post-extract:
cd ${WRKSRC}/util && rm configlexer.c configparser.c configparser.h
they will be regenerated automatically at build time (flex in base is
OK for this; src/usr.sbin/unbound does the same).
(TBH if anyone is spending time hacking on unbound, rather than fixing up
this patchset, it would be more useful to work out how to rip out the port
allocator and just use the OS port allocator instead, ideally in a way
which is controlled by a build or config option so it can be fed back
upstream, afaik that is the main obstacle to enabling unbound in base...)
UPDATE: Unbound - Add dns64 FLAVOR
The following diff adds a dns64 FLAVOR to the Unbound port to integrate the
DNS64 support as provided by the Ecdysis project.
Caveat.. do not run with the malloc flags J or U and thus also S.
This seems to expose bugs in the new code.
Anyone who would be better at tracking down such bugs interested
in trying to find the root cause and fix them?
I noticed a similar diff was posted back in 2011 for Unbound
1.4.9 but it never actually went in.
OK?
Index: Makefile
===
RCS file: /home/cvs/ports/net/unbound/Makefile,v
retrieving revision 1.50
diff -u -p -r1.50 Makefile
--- Makefile24 Mar 2013 21:33:24 - 1.50
+++ Makefile11 Apr 2013 18:28:22 -
@@ -3,9 +3,11 @@
COMMENT= validating DNS resolver
DISTNAME= unbound-1.4.20
+REVISION= 0
CATEGORIES=net
MASTER_SITES= http://www.unbound.net/downloads/
+MASTER_SITES0= http://comstyle.com/source/
HOMEPAGE= http://www.unbound.net/
MAINTAINER= Jakob Schlyter
@@ -33,6 +35,16 @@ CONFIGURE_ARGS+= --enable-allsymbols \
--with-pidfile=/var/unbound/var/run/unbound.pid \
--with-conf-file=/var/unbound/etc/unbound.conf \
--with-username=_unbound
+
+FLAVORS= dns64
+FLAVOR?=
+
+.if ${FLAVOR:Mdns64}
+PATCHFILES=unbound-1.4.20-dns64.diff.bz2:0
+PATCH_DIST_STRIP= -p1
+.endif
+
+SUPDISTFILES= unbound-1.4.20-dns64.diff.bz2:0
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/unbound
Index: distinfo
===
RCS file: /home/cvs/ports/net/unbound/distinfo,v
retrieving revision 1.30
diff -u -p -r1.30 distinfo
--- distinfo24 Mar 2013 21:33:24 - 1.30
+++ distinfo11 Apr 2013 18:28:29 -
@@ -1,2 +1,4 @@
+SHA256 (unbound-1.4.20-dns64.diff.bz2) =
SJ7x7Asg78BqUVczNXoqETyTeltYqX8waZ4koRkGQYU=
SHA256 (unbound-1.4.20.tar.gz) = FFJwAjB4c+VXNIpNdrYqwDaTfZwwM2EKhCUBjDeftW4=
+SIZE (unbound-1.4.20-dns64.diff.bz2) = 53002
SIZE (unbound-1.4.20.tar.gz) = 3613963
Index: pkg/DESCR
===
RCS file: /home/cvs/ports/net/unbound/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- pkg/DESCR 23 May 2008 06:52:21 - 1.1.1.1
+++ pkg/DESCR 10 Apr 2013 23:53:56 -
@@ -1,2 +1,5 @@
Unbound is an implementation of a recursive DNS resolver, that does caching
and DNSSEC validation.
+
+Flavors:
+dns64 - Build with DNS64 support
Index: pkg/PFRAG.shared
===
RCS file: pkg/PFRAG.shared
diff -N pkg/PFRAG.shared
--- pkg/PFRAG.shared23 May 2008 06:52:21 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,2 +0,0 @@
-@comment $OpenBSD: PFRAG.shared,v 1.1.1.1 2008/05/23 06:52:21 jakob Exp $
-@lib lib/libunbound.so.${LIBunbound_VERSION}
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/net/unbound/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- pkg/PLIST 12 Dec 2012 16:00:34 - 1.9
+++ pkg/PLIST 11 Apr 2013 00:07:50 -
@@ -1,10 +1,10 @@
@comment $OpenBSD: PLIST,v 1.9 2012/12/12 16:00:34 sthen Exp $
@newgroup _unbound:601
@newuser _unbound:601:601:daemon:Unbound Daemon:/var/unbound:/sbin/nologin
-%%SHARED%%
include/unbound.h
lib/libunbound.a
lib/libunbound.la
+@lib lib/libunbound.so.${LIBunbound_VERSION}
@man man/man1/unbound-host.1
@man man/man3/libunbound.3
@man man/man3/ub_cancel.3
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
