Re: Unbound in base, yes, what about ldns?
On Sun, 23 Mar 2014, Chris Smith wrote:
From: Chris Smith obsd_m...@chrissmith.org
To: Stuart Henderson s...@spacehopper.org
Cc: OpenBSD-Misc misc@openbsd.org
Date: Sun, 23 Mar 2014 22:09:00
Subject: Re: Unbound in base, yes, what about ldns?
...
How about this line added to rc.conf.local when using the package:
syslogd_flags=${syslogd_flags} -a /var/unbound/dev/log
Is it still needed or should it be removed?
Probably. If you're running chrooted and logging to syslog, you
should still need this line.
See the manual page for unbound.conf. A cursory reading indicates
it doesn't seem to have materially changed from the version in the
port/package. *But* cursory reading has let me and others down
badly in the past :-(
--
Dennis Davis dennisda...@fastmail.fm
Re: Unbound in base, yes, what about ldns?
On Thu, Mar 20, 2014 at 7:39 PM, Stuart Henderson s...@spacehopper.org wrote:
You can uninstall the package if you don't need it, or you can keep it
if you do need it (for example, for drill or the ldns-* tools).
How about this line added to rc.conf.local when using the package:
syslogd_flags=${syslogd_flags} -a /var/unbound/dev/log
Is it still needed or should it be removed?
Thanks,
Chris
Re: Unbound in base, yes, what about ldns?
On Fri, Mar 21, 2014 at 01:41:37PM +, Stuart Henderson wrote: Kind-of; things will work properly if the validator is enabled now, and it's less bad than having /var/unbound/etc writable, but would really prefer to not have anything at all in the chroot be writable by the unprivileged _unbound user. Privilege separation would be desirable for this. Just out of curiosity: how come the shipped unbound.conf file mentions the module-config: setting? It appears to me that validator iterator is the default, or am i missing something? Regards, Patrik Lundin
Re: Unbound in base, yes, what about ldns?
On Wed, Mar 19, 2014 at 7:44 PM, Chris Smith obsd_m...@chrissmith.org wrote: See the thread unbound dnssec revisited I started on 12/30/2013 for some hints. Looks like creating a new directory with the proper permissions is the best way to go. Now fixed in -current with a /var/unbound/db directory. Thanks Stuart! Chris
Re: Unbound in base, yes, what about ldns?
On 2014/03/21 09:30, Chris Smith wrote: On Wed, Mar 19, 2014 at 7:44 PM, Chris Smith obsd_m...@chrissmith.org wrote: See the thread unbound dnssec revisited I started on 12/30/2013 for some hints. Looks like creating a new directory with the proper permissions is the best way to go. Now fixed in -current with a /var/unbound/db directory. Thanks Stuart! Chris Kind-of; things will work properly if the validator is enabled now, and it's less bad than having /var/unbound/etc writable, but would really prefer to not have anything at all in the chroot be writable by the unprivileged _unbound user. Privilege separation would be desirable for this.
Re: Unbound in base, yes, what about ldns?
Thanks. 2014-03-20 1:44 GMT+02:00 Chris Smith obsd_m...@chrissmith.org: See the thread unbound dnssec revisited I started on 12/30/2013 for some hints. Looks like creating a new directory with the proper permissions is the best way to go. On Wed, Mar 19, 2014 at 7:01 PM, Àòàíàñ Âëàäèìèðîâ don.na...@gmail.com wrote: Hi, Sorry for Off-topic, but when you enable DNSSEC validation and fetch a root key with unbound-anchor(8) (needs root) the following error shows up in /var/log/messages: unbound: [0:0] error: could not open autotrust file for writing, /etc/root.key.29136-0: Permission denied May be this is because _unbound user has no rights to write to /var/unbound/etc/ after chroot. Am I correct? Any solutions? Best regards, Atanas
Re: Unbound in base, yes, what about ldns?
On 2014-03-19, Chris Smith obsd_m...@chrissmith.org wrote: On Wed, Mar 19, 2014 at 6:12 PM, Kenneth Westerback kwesterb...@gmail.com wrote: The unbound in base has it's own cut down version of ldns. No need for the package. Can I just uninstall the package after the fact or do some files need to be replaced? Thanks, Chris You can uninstall the package if you don't need it, or you can keep it if you do need it (for example, for drill or the ldns-* tools).
Re: Unbound in base, yes, what about ldns?
On 19 March 2014 18:09, Chris Smith obsd_m...@chrissmith.org wrote: Great to see Unbound in base, thanks. But what about ldns? I still have that installed as a package - removed the unbound package as per the -current instructions, but shouldn't the ldns package package be removed as well as I believe unbound requires it and therefore it would have to be built by base as well. Or am I off-base? Thanks, Chris The unbound in base has it's own cut down version of ldns. No need for the package. ... Ken
Re: Unbound in base, yes, what about ldns?
On Wed, Mar 19, 2014 at 6:12 PM, Kenneth Westerback kwesterb...@gmail.com wrote: The unbound in base has it's own cut down version of ldns. No need for the package. Can I just uninstall the package after the fact or do some files need to be replaced? Thanks, Chris
Re: Unbound in base, yes, what about ldns?
Hi, Sorry for Off-topic, but when you enable DNSSEC validation and fetch a root key with unbound-anchor(8) (needs root) the following error shows up in /var/log/messages: unbound: [0:0] error: could not open autotrust file for writing, /etc/root.key.29136-0: Permission denied May be this is because _unbound user has no rights to write to /var/unbound/etc/ after chroot. Am I correct? Any solutions? Best regards, Atanas
Re: Unbound in base, yes, what about ldns?
See the thread unbound dnssec revisited I started on 12/30/2013 for some hints. Looks like creating a new directory with the proper permissions is the best way to go. On Wed, Mar 19, 2014 at 7:01 PM, Атанас Владимиров don.na...@gmail.com wrote: Hi, Sorry for Off-topic, but when you enable DNSSEC validation and fetch a root key with unbound-anchor(8) (needs root) the following error shows up in /var/log/messages: unbound: [0:0] error: could not open autotrust file for writing, /etc/root.key.29136-0: Permission denied May be this is because _unbound user has no rights to write to /var/unbound/etc/ after chroot. Am I correct? Any solutions? Best regards, Atanas
Re: Unbound in base
The primary cause of this is unbound is not a drop-in replacement for bind, they use different utilities, like unbound use drill, and bind use dig and friends. Maybe I'm overlooking something, but that could be a problem with replacing bind by unbound but not with linking unbound to the build. Currently we have bind/nsd and apache/nginx all linked to the build. Anyway I'm just curious, so no complaining intended. Kind regards, Martijn Rijkeboer
Re: Unbound in base
On 11/23/2013 04:29 PM, Martijn Rijkeboer wrote: Hi, Just out of curiosity, what is holding the linking of Unbound to the build back? I'm not complaining since I'm using Unbound from ports without issues. I asked the question before. The primary cause of this is unbound is not a drop-in replacement for bind, they use different utilities, like unbound use drill, and bind use dig and friends. -- With best regards, Gregory Edigarov
Re: Unbound in base (review)
2012/3/26 Jakob Schlyter ja...@openbsd.org:
Any more feedback on this? We need more testing to proceed!
Unbound has been imported to work on in-tree (not yet linked to the
build) [1]. It compiles and functions on amd64 and i386. I can only
guess who is actually working on further integrating this tool in
base. Therefore I'm sending the diff below to everyb...@misc...for
inspiration.
--
Bjvrn Ketelaars
[1] http://marc.info/?l=openbsd-cvsm=133278525113948w=2
Index: distrib/sets/lists/base/mi
===
RCS file: /mnt/cvs/src/distrib/sets/lists/base/mi,v
retrieving revision 1.566
diff -u -r1.566 mi
--- distrib/sets/lists/base/mi 8 Mar 2012 19:28:45 - 1.566
+++ distrib/sets/lists/base/mi 2 Apr 2012 11:33:11 -
@@ -2548,6 +2548,7 @@
./usr/sbin/dig
./usr/sbin/dnssec-keygen
./usr/sbin/dnssec-signzone
+./usr/sbin/drill
./usr/sbin/dvmrpctl
./usr/sbin/dvmrpd
./usr/sbin/editmap
@@ -2699,6 +2700,12 @@
./usr/sbin/traceroute
./usr/sbin/traceroute6
./usr/sbin/trpt
+./usr/sbin/unbound
+./usr/sbin/unbound-anchor
+./usr/sbin/unbound-checkconf
+./usr/sbin/unbound-control
+./usr/sbin/unbound-control-setup
+./usr/sbin/unbound-host
./usr/sbin/usbdevs
./usr/sbin/user
./usr/sbin/useradd
@@ -5152,6 +5159,11 @@
./var/spool/uucppublic
./var/tmp
./var/tmp/vi.recover
+./var/unbound
+./var/unbound/etc
+./var/unbound/var
+./var/unbound/var/dev
+./var/unbound/var/run
./var/www
./var/www/bin
./var/www/bin/bgpctl
Index: distrib/sets/lists/etc/mi
===
RCS file: /mnt/cvs/src/distrib/sets/lists/etc/mi,v
retrieving revision 1.146
diff -u -r1.146 mi
--- distrib/sets/lists/etc/mi 2 Apr 2012 03:08:44 - 1.146
+++ distrib/sets/lists/etc/mi 2 Apr 2012 11:33:11 -
@@ -166,6 +166,7 @@
./etc/rc.d/sshd
./etc/rc.d/statd
./etc/rc.d/syslogd
+./etc/rc.d/unbound
./etc/rc.d/tftpd
./etc/rc.d/watchdogd
./etc/rc.d/wsmoused
@@ -244,6 +245,9 @@
./var/named/standard/loopback
./var/named/standard/loopback6.arpa
./var/run/utmp
+./var/unbound/etc/root.hint
+./var/unbound/etc/unbound.conf
+./var/unbound/var/run/root.key
./var/www/cgi-bin/printenv
./var/www/cgi-bin/test-cgi
./var/www/conf/bgplg.css
Index: distrib/sets/lists/man/mi
===
RCS file: /mnt/cvs/src/distrib/sets/lists/man/mi,v
retrieving revision 1.1128
diff -u -r1.1128 mi
--- distrib/sets/lists/man/mi 29 Mar 2012 11:03:59 - 1.1128
+++ distrib/sets/lists/man/mi 2 Apr 2012 11:33:11 -
@@ -353,6 +353,7 @@
./usr/share/man/man1/dirname.1
./usr/share/man/man1/domainname.1
./usr/share/man/man1/dprofpp.1
+./usr/share/man/man1/drill.1
./usr/share/man/man1/du.1
./usr/share/man/man1/echo.1
./usr/share/man/man1/ed.1
@@ -758,6 +759,7 @@
./usr/share/man/man1/uname.1
./usr/share/man/man1/uncompress.1
./usr/share/man/man1/unexpand.1
+./usr/share/man/man1/unbound-host.1
./usr/share/man/man1/unifdef.1
./usr/share/man/man1/uniq.1
./usr/share/man/man1/units.1
@@ -2537,6 +2539,7 @@
./usr/share/man/man5/texinfo.5
./usr/share/man/man5/ttys.5
./usr/share/man/man5/tzfile.5
+./usr/share/man/man5/unbound.conf.5
./usr/share/man/man5/usermgmt.conf.5
./usr/share/man/man5/utmp.5
./usr/share/man/man5/uuencode.5
@@ -3040,6 +3043,10 @@
./usr/share/man/man8/ttyflags.8
./usr/share/man/man8/tunefs.8
./usr/share/man/man8/umount.8
+./usr/share/man/man8/unbound-anchor.8
+./usr/share/man/man8/unbound-checkconf.8
+./usr/share/man/man8/unbound-control.8
+./usr/share/man/man8/unbound.8
./usr/share/man/man8/updatedb.8
./usr/share/man/man8/usbdevs.8
./usr/share/man/man8/uucpd.8
Index: etc/Makefile
===
RCS file: /mnt/cvs/src/etc/Makefile,v
retrieving revision 1.316
diff -u -r1.316 Makefile
--- etc/Makefile1 Apr 2012 18:32:51 - 1.316
+++ etc/Makefile2 Apr 2012 11:33:11 -
@@ -53,9 +53,9 @@
inetd isakmpd ldapd ldattach ldpd lpd mopd mrouted named nginx \
nsd ntpd ospfd ospf6d portmap pflogd rarpd rbootd relayd ripd \
route6d rtadvd rtsold rwhod sasyncd sendmail sensorsd smtpd \
- snmpd spamd sshd syslogd watchdogd wsmoused xdm ypbind ypldap \
- yppasswdd ypserv kdc kadmind kpasswdd nfsd mountd lockd statd \
- spamlogd sndiod popa3d tftpd
+ snmpd spamd sshd syslogd unbound watchdogd wsmoused xdm ypbind \
+ ypldap yppasswdd ypserv kdc kadmind kpasswdd nfsd mountd lockd \
+ statd spamlogd sndiod popa3d tftpd
MISETS=base${OSrev}.tgz comp${OSrev}.tgz \
man${OSrev}.tgz game${OSrev}.tgz etc${OSrev}.tgz
@@ -219,6 +219,13 @@
${DESTDIR}/var/named/standard/loopback; \
${INSTALL} -c -o root -g wheel -m 644 db.loopback6.arpa \
${DESTDIR}/var/named/standard/loopback6.arpa
+ cd unbound;
Re: Unbound in base (review)
Any more feedback on this? We need more testing to proceed! jakob
Re: Unbound in base
2012/2/15 Ralf r...@ackstorm.de (mailto:r...@ackstorm.de):
I have briefly tested your tarball on hppa yesterday. It compiles
and works so far.
Nice to hear :-)
I haven't gotten the DNSSec to work, so I ran with module-config:
iterator. But I'm not too familiar with DNSsec, so I might have done
something wrong on that part. And I cheated a bit when compiling and
installing, as the machine didn't have the full source tree, so I did
some steps manually, maybe I left something out.
The supplied unbound.conf should work (mental note to myself: assumption is
the mother of all b). Could you check that there is a root.key in
/var/unbound/etc? If not, please run unbound-anchor manually, do not forget to
set the right permissions on root.key or run as _unbound (this is part of the
current unbound rc.d-script - rc_pre()).
If there is a root.key you could use drill to test:
drill @127.0.0.1 www.nic.cz (http://nic.cz) (rcode: noerror)
drill @127.0.0.1 www.rhybar.cz (http://rhybar.cz) (rcode: servfail)
or use dig:
dig @127.0.0.1 www.nic.cz (http://www.nic.cz) +dnssec (ad flag should be set)
Make sure that unbound is running ...
There was an issue with the rc.diff patch:
+ if [ X${unbound_flags} != XNO ]; then
+ echo -n unbound-control-setup: generating self-signed
certificate and private keys...
+ if sudo -u _unbound unbound-control-setup /dev/null
21; then
+ echo done.
+ else
+ echo failed.
+ fi
+ fi
+ fi
You are right! I will correct this. BTW, in the current unbound.conf,
control-enable is not set to 'yes'. Even if there are keys and certificates
unbound-control will not work as it should. The idea is to use unbound-control
for stopping and starting the daemon (rc.d-script), so this has to be changed
as well.
In the meantime I simplified the rc.d-script a bit:
#!/bin/sh
#
# $OpenBSD: unbound
daemon=/usr/sbin/unbound-control
daemon_flags=-c /var/unbound/etc/unbound.conf
. /etc/rc.d/rc.subr
pexp=unbound${daemon_flags:+ ${daemon_flags}}
rc_reload=NO
rc_pre() {
sudo -u _unbound /usr/sbin/unbound-anchor
}
rc_start() {
${daemon} start
}
rc_stop() {
${daemon} stop
}
rc_cmd $1
As you can see rc_pre() runs unbound-anchor. This is still a point of
discussionb
--
BjC6rn Ketelaars
Re: Unbound in base
From unbound-anchor.8 I understand that unbound-anchor can be run from the
command line, or run as part of startup scripts _before_ the actual
(unbound)
DNS server is started. So there is no need for DNS. Proposal therefor is to
run unbound-anchor automatically before starting the unbound daemon (rc_pre
in
unbound rc-script).
This (i.e. connecting out to https://data.iana.org from the system startup
scripts) should *not* happen by default even if unbound is enabled. There
would need to be a separate option controlling this.
How about letting /var/unbound/etc/unbound.conf control this behavior?
In the startup script (rc.d-script):
rc_pre() {
if ! egrep # *auto-trust-anchor-file: /var/unbound/etc/unbound.conf
/dev/null; then
sudo -u _unbound /usr/sbin/unbound-anchor
fi
}
The same behavior can be obtained by writing a wrapper. Although these
'solutions' work, they are not elegant. What say thou?
Re: Unbound in base
Hello,
bjorn.ketela...@hydroxide.nl (Bjvrn Ketelaars), 2012.02.15 (Wed) 10:23 (CET):
From unbound-anchor.8 I understand that unbound-anchor can be run from the
command line, or run as part of startup scripts _before_ the actual
(unbound)
DNS server is started. So there is no need for DNS. Proposal therefor is
to
run unbound-anchor automatically before starting the unbound daemon
(rc_pre in
unbound rc-script).
This (i.e. connecting out to https://data.iana.org from the system startup
scripts) should *not* happen by default even if unbound is enabled. There
would need to be a separate option controlling this.
How about letting /var/unbound/etc/unbound.conf control this behavior?
In the startup script (rc.d-script):
rc_pre() {
if ! egrep # *auto-trust-anchor-file: /var/unbound/etc/unbound.conf
/dev/null; then
sudo -u _unbound /usr/sbin/unbound-anchor
would fail if ``!root_sudo'' is set in sudoers(5). But, quoting
sudoers(5):
Disabling root_sudo provides no real additional security; it exists
purely for historical reasons. This flag is on by default.
Bye, Marcus
fi
}
The same behavior can be obtained by writing a wrapper. Although these
'solutions' work, they are not elegant. What say thou?
Re: Unbound in base
* Bjvrn Ketelaars bjorn.ketela...@hydroxide.nl [2012-02-15 18:04]: 2012/2/15 Ralf r...@ackstorm.de (mailto:r...@ackstorm.de): I haven't gotten the DNSSec to work, so I ran with module-config: iterator. But I'm not too familiar with DNSsec, so I might have done something wrong on that part. And I cheated a bit when compiling and installing, as the machine didn't have the full source tree, so I did some steps manually, maybe I left something out. The supplied unbound.conf should work (mental note to myself: assumption is the mother of all b). Could you check that there is a root.key in /var/unbound/etc? If not, please run unbound-anchor manually, do not forget to set the right permissions on root.key or run as _unbound (this is part of the current unbound rc.d-script - rc_pre()). The problem was the clock of this old machine. I had ntpd configured, but unfortunately without -s. The clock was somewhere around year 2020, causing some certificate verification in unbound-anchor to fail with message the PKCS7 signature failed. After fixing the clock it works now with your default config on hppa. Cheers, Ralf
Re: Unbound in base
On Mon, 13 Feb 2012 22:35:15 +0100 BjC6rn Ketelaars bjorn.ketela...@hydroxide.nl wrote: Hello, After some recent discussions [1, 2] on the topic of unbound in base, and (more important) really liking the idea of an alternative for BIND in base, I made a start with fitting the different pieces of the puzzle. What is finished: 1.) Integration of ldns 1.6.12 and unbound 1.4.15 and writing of relevant Makefile wrappers. Wrapper script also compiles and installs drill; 2.) Testing (read: does it compile and work) on AMD64. Stuart Henderson had some good remarks on integrating the above [3]. What do you guys think of the following: What to do with the BIND tools (dig/host/nslookup)? I would live them alone. They are used in most of the scripts all over the place. I.e. have a usr.sbin/bind-utils in the source tree. Unbound offers drill. From drill.1: The name drill is a pun on dig. With drill you should be able get even more information than with dig.. Proposal therefore is to replace the BIND tools with drill. Not, see above. Do we run unbound-anchor automatically? if so, how do we handle possibly not having working DNS at that time to resolve data.iana.org (http://data.iana.org) (http://data.iana.org)? From unbound-anchor.8 I understand that unbound-anchor can be run from the command line, or run as part of startup scripts _before_ the actual (unbound) DNS server is started. So there is no need for DNS. Proposal therefor is to run unbound-anchor automatically before starting the unbound daemon (rc_pre in unbound rc-script). Agreed. How and when do we automatically generate unbound-control keys? if so, where should that be done? b From unbound-control.8: The script unbound-control-setup generates these control keys in the default run directory. If you change the access control permissions on the key files you can decide who can use unbound-control. Run the script under the same username as you have configured in unbound.conf or as root, so that the daemon is permitted to read the files, for example with: sudo -u unbound unbound-control-setup. If you have not configured a username in unbound.conf, the keys need read permission for the user credentials under which the daemon is started. The script preserves private keys present in the directory. After running the script as root, turn on control-enable in unbound.conf. The unbound-control-script can be called from rc-make_keys(). The knob 'control-enable' can be set as default. unbound-control should be renamed to more convenient 'unboundctl'. After tar/gzip the source files and Makefile wrappers weigh ~4.6MB. A bit to large to send to this list. if anyone feels like looking at the workbdo not hesitate to mail me. Again, what do you guys think? Kind regards, BjC6rn [1] http://marc.info/?l=openbsd-miscm=132205020820910w=2 [2] http://marc.info/?l=openbsd-techm=132573371521516w=2 [3] http://marc.info/?l=openbsd-miscm=132217547525487w=2
Re: Unbound in base
Hello, Why replacing bind ? Kind Regards Peter - Oorspronkelijk bericht - Van: Bjvrn Ketelaars [mailto:bjorn.ketela...@hydroxide.nl] Verzonden: Monday, February 13, 2012 10:35 PM Aan: misc@openbsd.org misc@openbsd.org; t...@openbsd.org t...@openbsd.org Onderwerp: Unbound in base Hello, After some recent discussions [1, 2] on the topic of unbound in base, and (more important) really liking the idea of an alternative for BIND in base, I made a start with fitting the different pieces of the puzzle. What is finished: 1.) Integration of ldns 1.6.12 and unbound 1.4.15 and writing of relevant Makefile wrappers. Wrapper script also compiles and installs drill; 2.) Testing (read: does it compile and work) on AMD64. Stuart Henderson had some good remarks on integrating the above [3]. What do you guys think of the following: What to do with the BIND tools (dig/host/nslookup)? Unbound offers drill. From drill.1: The name drill is a pun on dig. With drill you should be able get even more information than with dig.. Proposal therefore is to replace the BIND tools with drill. Do we run unbound-anchor automatically? if so, how do we handle possibly not having working DNS at that time to resolve data.iana.org (http://data.iana.org) (http://data.iana.org)? From unbound-anchor.8 I understand that unbound-anchor can be run from the command line, or run as part of startup scripts _before_ the actual (unbound) DNS server is started. So there is no need for DNS. Proposal therefor is to run unbound-anchor automatically before starting the unbound daemon (rc_pre in unbound rc-script). How and when do we automatically generate unbound-control keys? if so, where should that be done? b From unbound-control.8: The script unbound-control-setup generates these control keys in the default run directory. If you change the access control permissions on the key files you can decide who can use unbound-control. Run the script under the same username as you have configured in unbound.conf or as root, so that the daemon is permitted to read the files, for example with: sudo -u unbound unbound-control-setup. If you have not configured a username in unbound.conf, the keys need read permission for the user credentials under which the daemon is started. The script preserves private keys present in the directory. After running the script as root, turn on control-enable in unbound.conf. The unbound-control-script can be called from rc-make_keys(). The knob 'control-enable' can be set as default. After tar/gzip the source files and Makefile wrappers weigh ~4.6MB. A bit to large to send to this list. if anyone feels like looking at the workbdo not hesitate to mail me. Again, what do you guys think? Kind regards, BjC6rn [1] http://marc.info/?l=openbsd-miscm=132205020820910w=2 [2] http://marc.info/?l=openbsd-techm=132573371521516w=2 [3] http://marc.info/?l=openbsd-miscm=132217547525487w=2
Re: Unbound in base
On Tue, Feb 14, 2012 at 10:09 AM, Peter van Oord van der Vlies peter.vanoordvandervl...@itisit.nl wrote: Hello, Why replacing bind ? That's a good question, Peter. Welcome aboard. https://www.isc.org/software/bind/advisories/cve-2012-1033 Kind Regards Peter -- ### Coonardoo - PQP8P=P8QP:P0 Q QQP=Q / The Well In The Shadow / Le Puits Dans L'Ombre ###
Re: Unbound in base
On Tue, 14 Feb 2012 08:09:16 + Peter van Oord van der Vlies peter.vanoordvandervl...@itisit.nl wrote: Hello, Why replacing bind ? Because bind is full of security related bugs and a bloatware. Yours C. O. Kind Regards Peter - Oorspronkelijk bericht - Van: Bjvrn Ketelaars [mailto:bjorn.ketela...@hydroxide.nl] Verzonden: Monday, February 13, 2012 10:35 PM Aan: misc@openbsd.org misc@openbsd.org; t...@openbsd.org t...@openbsd.org Onderwerp: Unbound in base Hello, After some recent discussions [1, 2] on the topic of unbound in base, and (more important) really liking the idea of an alternative for BIND in base, I made a start with fitting the different pieces of the puzzle. What is finished: 1.) Integration of ldns 1.6.12 and unbound 1.4.15 and writing of relevant Makefile wrappers. Wrapper script also compiles and installs drill; 2.) Testing (read: does it compile and work) on AMD64. Stuart Henderson had some good remarks on integrating the above [3]. What do you guys think of the following: What to do with the BIND tools (dig/host/nslookup)? Unbound offers drill. From drill.1: The name drill is a pun on dig. With drill you should be able get even more information than with dig.. Proposal therefore is to replace the BIND tools with drill. Do we run unbound-anchor automatically? if so, how do we handle possibly not having working DNS at that time to resolve data.iana.org (http://data.iana.org) (http://data.iana.org)? From unbound-anchor.8 I understand that unbound-anchor can be run from the command line, or run as part of startup scripts _before_ the actual (unbound) DNS server is started. So there is no need for DNS. Proposal therefor is to run unbound-anchor automatically before starting the unbound daemon (rc_pre in unbound rc-script). How and when do we automatically generate unbound-control keys? if so, where should that be done? b From unbound-control.8: The script unbound-control-setup generates these control keys in the default run directory. If you change the access control permissions on the key files you can decide who can use unbound-control. Run the script under the same username as you have configured in unbound.conf or as root, so that the daemon is permitted to read the files, for example with: sudo -u unbound unbound-control-setup. If you have not configured a username in unbound.conf, the keys need read permission for the user credentials under which the daemon is started. The script preserves private keys present in the directory. After running the script as root, turn on control-enable in unbound.conf. The unbound-control-script can be called from rc-make_keys(). The knob 'control-enable' can be set as default. After tar/gzip the source files and Makefile wrappers weigh ~4.6MB. A bit to large to send to this list. if anyone feels like looking at the workbdo not hesitate to mail me. Again, what do you guys think? Kind regards, BjC6rn [1] http://marc.info/?l=openbsd-miscm=132205020820910w=2 [2] http://marc.info/?l=openbsd-techm=132573371521516w=2 [3] http://marc.info/?l=openbsd-miscm=132217547525487w=2
Re: Unbound in base
2012/2/13 Stuart Henderson s...@spacehopper.org: ... After tar/gzip the source files and Makefile wrappers weigh ~4.6MB. A bit to large to send to this list. if anyone feels like looking at the workbdo not hesitate to mail me. Please do. It would be nice to put them on a public server. WIP can be found here: http://goo.gl/BIRR5 .tar.gz contains a README which explains the status -- Bjvrn Ketelaars
Re: Unbound in base
Let's not crosspost replies, misc is more suitable for this one. CCs trimmed. On 2012/02/14 08:09, Peter van Oord van der Vlies wrote: Hello, Why replacing bind ? The version we have is in need of an update. Due to some of the design decisions made for BIND 10 that's not really going to be suitable for inclusion in base so even if we were to update to a newer BIND 9 now, we'd still need to look elsewhere in future, so considering that something fairly suitable is already available, imho rather than update BIND (which is not just a simple task of importing the code, we have quite a few local changes which can't be applied directly), it makes more sense to move directly there,
Re: Unbound in base
On 2012 Feb 14 (Tue) at 13:23:01 +0400 (+0400), Mo Libden wrote: :14 QP5P2QP0P;Q 2012, 12:59 PQ Gregory Edigarov g...@bestnet.kharkov.ua: : On Tue, 14 Feb 2012 08:09:16 + : Peter van Oord van der Vlies peter.vanoordvandervl...@itisit.nl wrote: : : Hello, : : Why replacing bind ? : : Because bind is full of security related bugs and a bloatware. : :Oh come on! :They say about the same thing about sendmail for years (decades already?). :Still it is in the base. Did you notice that there is lots of work being done to replace sendmail? Yes, there is an interest in replacing bind (and sendmail). However, we are doing it slowly and cautiously, to ensure we do not make the situation worse. -- Any sufficiently advanced technology is indistinguishable from a rigged demo.
Re: Unbound in base
On Tue, 14 Feb 2012 13:23:01 +0400 Mo Libden m0lib...@mail.ru wrote: 14 QP5P2QP0P;Q 2012, 12:59 PQ Gregory Edigarov g...@bestnet.kharkov.ua: On Tue, 14 Feb 2012 08:09:16 + Peter van Oord van der Vlies peter.vanoordvandervl...@itisit.nl wrote: Hello, Why replacing bind ? Because bind is full of security related bugs and a bloatware. Oh come on! They say about the same thing about sendmail for years (decades already?). Still it is in the base. Are you spreading FUD here, or there are real cases with the version of BIND that is in the base? well, better answer was just given by stu@. BIND 10 requires at least Python 3.1 -- With best regards, Gregory Edigarov
Re: Unbound in base
On Tue, Feb 14, 2012 at 01:23:01PM +0400, Mo Libden wrote: 14 QP5P2QP0P;Q 2012, 12:59 PQ Gregory Edigarov g...@bestnet.kharkov.ua: On Tue, 14 Feb 2012 08:09:16 + Peter van Oord van der Vlies peter.vanoordvandervl...@itisit.nl wrote: Hello, Why replacing bind ? Because bind is full of security related bugs and a bloatware. Oh come on! They say about the same thing about sendmail for years (decades already?). Still it is in the base. smtpd(8) is underway. Also there is no proper MTA implementation out there served under the BSD license (i.e. Postfix has IBM license). Unbound (and also nsd) is a good and lightweight alternative to sendmail using the BSD license. License stuff is more important than it sounds. IMO the separate development of a resolver (unbound) and an authoritive nameserver (nsd) is better than having all functionality within one server (named). -- Oliver PETER oli...@opdns.de 0x456D688F
Re: Unbound in base
* Peter van Oord van der Vlies peter.vanoordvandervl...@itisit.nl [2012-02-14 09:11]: Why replacing bind ? 1) because it's shit (yes yes vixie, the next release won't be written by drunken grad students and fix all design and implementation issues, we hear that since bind4 at least) 2) it's a dead end anyway - i have never seen such a dramatic design fuckup as the bind10 design docs, and anything depending on PYTHON (gimme a break) will never make it into base anyway. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Unbound in base
Henning Brauer wrote [2012-02-14 13:52+0100]: anything depending on PYTHON MY WOMAN! (gimme a break) Aeh. Man. will never make it into base anyway. If it were true! --steffen
Re: Unbound in base
On Tue, Feb 14, 2012, Vitali wrote: On Tue, Feb 14, 2012 at 10:09 AM, Peter van Oord van der Vlies Why replacing bind ? https://www.isc.org/software/bind/advisories/cve-2012-1033 Bad CVE choice... That's a design issue in DNS, not a vulnerability in BIND. And if you want to throw CVEs around: Unbound VU#209659 CVE-2011-4528 Unbound denial of service vulnerabilities from nonstandard redirection and denial of existence But at least it seems to have less problems than bind(?)
Re: Unbound in base
On 2012-02-14, Gregory Edigarov g...@bestnet.kharkov.ua wrote: unbound-control should be renamed to more convenient 'unboundctl'. and break scripts that are meant to work with cross-OS deployments?
Re: Unbound in base
On Tue, 14 Feb 2012 17:16:15 + (UTC) Stuart Henderson s...@spacehopper.org wrote: On 2012-02-14, Gregory Edigarov g...@bestnet.kharkov.ua wrote: unbound-control should be renamed to more convenient 'unboundctl'. and break scripts that are meant to work with cross-OS deployments? nah, he is talking bout convinience, not sanity, eh? # grep unbound-control ~/.kshrc alias ubc=/usr/local/sbin/unbound-control
