Re: Unbound in base, yes, what about ldns?
moved from misc to tech
On 2014/03/23 18:09, Chris Smith wrote:
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
I was waiting to be sure about this before adding an extra log socket in
the jail.
Unbound opens /dev/log pre-chroot, so under normal conditions this is
not necessary, *however* if syslogd is restarted, the old socket is
no longer valid, so Unbound stops logging.
So I think yes we should have this. Of course now this is in base,
it needs to be in syslogd's startup script rather than a local addition,
so you can remove it from rc.conf.local.
Index: rc.d/syslogd
===
RCS file: /cvs/src/etc/rc.d/syslogd,v
retrieving revision 1.2
diff -u -p -r1.2 syslogd
--- rc.d/syslogd15 Mar 2014 00:59:50 - 1.2
+++ rc.d/syslogd23 Mar 2014 22:18:05 -
@@ -15,6 +15,8 @@ rc_pre() {
daemon_flags=${daemon_flags} -a /var/named/dev/log
[ X${nsd_flags} != XNO ] rm -f /var/nsd/dev/log \
daemon_flags=${daemon_flags} -a /var/nsd/dev/log
+ [ X${unbound_flags} != XNO ] rm -f /var/unbound/dev/log \
+ daemon_flags=${daemon_flags} -a /var/unbound/dev/log
[ -d /var/empty ] rm -f /var/empty/dev/log \
mkdir -p -m 0555 /var/empty/dev \
daemon_flags=${daemon_flags} -a /var/empty/dev/log
Index: mtree/4.4BSD.dist
===
RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v
retrieving revision 1.245
diff -u -p -r1.245 4.4BSD.dist
--- mtree/4.4BSD.dist 21 Mar 2014 00:23:15 - 1.245
+++ mtree/4.4BSD.dist 23 Mar 2014 22:18:05 -
@@ -1357,6 +1357,11 @@ vi.recovermode=01777
# ./var/unbound
unbound
+# ./var/unbound/dev
+devuname=root gname=wheel mode=0755
+# ./var/unbound/dev
+..
+
# ./var/unbound/etc
etcuname=root gname=wheel mode=0755
# ./var/unbound/etc
Re: Unbound in base, yes, what about ldns?
I was waiting to be sure about this before adding an extra log socket in
the jail.
Unbound opens /dev/log pre-chroot, so under normal conditions this is
not necessary, *however* if syslogd is restarted, the old socket is
no longer valid, so Unbound stops logging.
So I think yes we should have this. Of course now this is in base,
it needs to be in syslogd's startup script rather than a local addition,
so you can remove it from rc.conf.local.
Seems sensible. We've done this in other software, though generally I
think they end up always opening the one inside the jail, even upfront.
Index: rc.d/syslogd
===
RCS file: /cvs/src/etc/rc.d/syslogd,v
retrieving revision 1.2
diff -u -p -r1.2 syslogd
--- rc.d/syslogd 15 Mar 2014 00:59:50 - 1.2
+++ rc.d/syslogd 23 Mar 2014 22:18:05 -
@@ -15,6 +15,8 @@ rc_pre() {
daemon_flags=${daemon_flags} -a /var/named/dev/log
[ X${nsd_flags} != XNO ] rm -f /var/nsd/dev/log \
daemon_flags=${daemon_flags} -a /var/nsd/dev/log
+ [ X${unbound_flags} != XNO ] rm -f /var/unbound/dev/log \
+ daemon_flags=${daemon_flags} -a /var/unbound/dev/log
[ -d /var/empty ] rm -f /var/empty/dev/log \
mkdir -p -m 0555 /var/empty/dev \
daemon_flags=${daemon_flags} -a /var/empty/dev/log
Index: mtree/4.4BSD.dist
===
RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v
retrieving revision 1.245
diff -u -p -r1.245 4.4BSD.dist
--- mtree/4.4BSD.dist 21 Mar 2014 00:23:15 - 1.245
+++ mtree/4.4BSD.dist 23 Mar 2014 22:18:05 -
@@ -1357,6 +1357,11 @@ vi.recover mode=01777
# ./var/unbound
unbound
+# ./var/unbound/dev
+dev uname=root gname=wheel mode=0755
+# ./var/unbound/dev
+..
+
# ./var/unbound/etc
etc uname=root gname=wheel mode=0755
# ./var/unbound/etc
Re: Unbound in base (review)
Any more feedback on this? We need more testing to proceed! jakob
Unbound in base (review)
2012/3/14 Jakob Schlyter ja...@kirei.se (mailto:ja...@kirei.se): Could you provide an update complete tarfil for review by other developers? I think we should start considering importing this. Latest iteration: http://gateway.hydroxide.nl/OpenBSD/unbound-wip.9.tar.gz Current status includes work on suggestions / remarks from Jakob: - run unbound-control-setup if no keys found; - shipping of a default root.key (for use with auto-trust-anchor-file in unbound.conf). This 'solves' a difficult and ugly workaround with unbound-anchor as suggested in previous iterations; - start nsd before unbound. Detailed information can be found in the tarball (README). -- BjC6rn Ketelaars
Re: Unbound in base
The latest iteration includes: - Removal of ldns-includes, -library and -manpages; - Static link of ldns; - No shared libraries. There was a nasty config-error in Makefile.bsd-wrapper which has been fixed in: http://gateway.hydroxide.nl/OpenBSD/unbound-wip.8.tar.gz This iteration also has removed some cruft files from both ldns and unbound. The tarball includes a README with additional information.
Re: Unbound in base
- Could you try to link ldns static and not install neither the ldns library, include files nor the man-pages? The latest iteration includes: - Removal of ldns-includes, -library and -manpages; - Static link of ldns; - No shared libraries. Tarball: http://gateway.hydroxide.nl/OpenBSD/unbound-wip.6.tar.gz Additional points of discussion: 1.) This iteration installs both drill and unbound-host as dns-tooling. Unbound-host is part of unbound and, preferably, should be installed. Drill however is a different story: it is part of ldns. Are there arguments for installing / not installing drill? 2.) Are there arguments for installing / not installing both tools? OpenBSD base already has some dns-tooling (dig, host, nslookup - from BIND). Installing unbound-host and drill might be abundant? -- Bjvrn Ketelaars
Re: Unbound in base
On 2012 Feb 23 (Thu) at 09:37:57 +0100 (+0100), Bjvrn Ketelaars wrote: : - Could you try to link ldns static and not install neither the ldns :library, include files nor the man-pages? : :The latest iteration includes: : :- Removal of ldns-includes, -library and -manpages; :- Static link of ldns; :- No shared libraries. : :Tarball: : :http://gateway.hydroxide.nl/OpenBSD/unbound-wip.6.tar.gz : :Additional points of discussion: : :1.) This iteration installs both drill and unbound-host as :dns-tooling. Unbound-host is part of unbound and, preferably, should :be installed. Drill however is a different story: it is part of ldns. :Are there arguments for installing / not installing drill? :2.) Are there arguments for installing / not installing both tools? :OpenBSD base already has some dns-tooling (dig, host, nslookup - from :BIND). Installing unbound-host and drill might be abundant? : I would like to keep dig/host/nslookup, since they are de-facto standard tools. However, I still think we should include drill/unbound-host because (as I understand it), they provide some unbound-specific commands. -- Goldenstern's Rules: (1) Always hire a rich attorney. (2) Never buy from a rich salesman.
Re: Unbound in base
Hi Bjvrn, First - thanks a lot for doing this; it has been on my todo-list for ages and I really appreciate this getting done. - Have you considered getting rid of all the ldns cruft that we would not use anyway? - Could you try to link ldns static and not install neither the ldns library, include files nor the man-pages? If we really want to install ldns, I think we should build it from src/lib/-something and do it right. Or we don't install it at all and link unbound static with ldns. jakob
Re: Unbound in base
Latest iteration of trying to get unbound to fit in OpenBSD base can be found here: http://gateway.hydroxide.nl/OpenBSD/unbound-wip.5.tar.gz Quite a few things have changed: - better integration of ldns in unbound by writing a better Makefile.bsd-wrapper (thanks to Ralf -at- ackstorm -dot- de); - builds and installs on amd64 / i386 - builds and installs on sparc64 (thanks to Ralf) - builds and installs on vax - simh emulator (again, thanks to Ralf) From README (included with tarball): - Use of unbound 1.4.16 and ldns 1.6.12 - Integration of unbound is non invasive. Meaning no other pieces of software are being removed. Just another flag in rc.conf - drill is installed (as possible addition to BIND-tooling) - Unbound-control-setup generates self-signed certificate and private keys - etc/rc - make_keys() - Added _unbound user and group (picked 102 as uid) - Some additions to etc/Makefile (directory creation and installation of root.hint and unbound.conf) - rc.d-script for control of unbound daemon - rc.d-script contains rc_pre() to create anchor file (root.key). However, this function does not run per default (depending on specific setting in unbound.conf) Anybody feels like testing and / or commenting the above?
Re: Unbound in base
I agree, however I cannot help with these arches as I do not have access to them. Anyone does? I tested another arch, alpha with -current from 2012-02-12. A couple of build scripts needed executable bits to build successfully, like install-sh and libtool (hppa had the same issue, of course, forgot to mention that). Other than that, it works fine. Thanks for the feedback! The executable bits got lost during archiving (using tar _without_ the -p flag). My fault... I made an update based on unbound 1.4.16 and different pieces of feedback. Current status: - Use of unbound 1.4.16 and ldns 1.6.12 - Integration of unbound is non invasive. Meaning no other pieces of software are being removed. Just another flag in rc.conf - drill is installed (as possible addition to BIND-tooling) - Unbound-control-setup generates self-signed certificate and private keys - etc/rc - make_keys() - Added _unbound user and group (picked 102 as uid) - Some additions to etc/Makefile (directory creation and installation of root.hint and unbound.conf) - rc.d-script for control of unbound daemon - rc.d-script contains rc_pre() to create anchor file (root.key). However, this function does not run per default (depending on specific setting in unbound.conf) - executable bits are preserved Updated set of files and diffs are here: http://gateway.hydroxide.nl/OpenBSD/unbound-wip.2.tar.gz -- Bjvrn Ketelaars
Re: Unbound in base
There is an other problem with replacing bind with unbound and nsd. If you have a setup where you need to do authoritative and recursive resolving of domains with the same socket and you have to synchronise with an extern dns server over zone transfers. This setup is not possible at the moment with unbound and nsd. You need a feature in unbound that it forwards zone transfer requests to another dns server. I think it could be possible with the unbound python-extension to implement such a feature, but in OpenBSD Base there will no unbound with this kind of extension. I think we need modern bind in ports if we do the replacement. So that the admins out there could easily use OpenBSD as a DNS-Server with such extra features. -- Jan Klemkow
Re: Unbound in base
On 2012/02/17 10:38, Jan Klemkow wrote: I think we need modern bind in ports if we do the replacement. So that the admins out there could easily use OpenBSD as a DNS-Server with such extra features. Yes of course. It's also needed for people doing split-horizon with views, and various other features. I started on this a while ago but haven't spent much time on it recently due to lack of interest.
Re: Unbound in base
* Jan Klemkow j.klem...@wemelug.de [2012-02-17 10:45]: There is an other problem with replacing bind with unbound and nsd. If you have a setup where you need to do authoritative and recursive resolving of domains with the same socket and you have to synchronise with an extern dns server over zone transfers. I see no reason to support or even remotely take such a stupid setup into consideration. -- 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
I was working on replacing bind with unbound and nsd a half year ago. I run into this problem. I think in local networks you get such setups where you have to serve clients with global request like google.de and local requests like mail.inhouse.company.com. I just want to hint this problem. In my opinion the replacement of bind with unbound and nsd is more important than the support for this kind of setups :-) On Fri, Feb 17, 2012 at 12:01:46PM +0100, Henning Brauer wrote: * Jan Klemkow j.klem...@wemelug.de [2012-02-17 10:45]: There is an other problem with replacing bind with unbound and nsd. If you have a setup where you need to do authoritative and recursive resolving of domains with the same socket and you have to synchronise with an extern dns server over zone transfers. I see no reason to support or even remotely take such a stupid setup into consideration. -- 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/ -- Jan Klemkow
Re: Unbound in base
On Fri, Feb 17, 2012 at 01:18:33PM +0100, Jan Klemkow wrote: | I was working on replacing bind with unbound and nsd a half year ago. | I run into this problem. I think in local networks you get such setups | where you have to serve clients with global request like google.de and | local requests like mail.inhouse.company.com. unbound supports (simple) authoritative data. If that's not sufficient for your use, just add an IP address on your local interface, bind the two daemons to different addresses and configure unbound to query NSD for your local domain(s). | I just want to hint this problem. | In my opinion the replacement of bind with unbound and nsd is more | important than the support for this kind of setups :-) Here, we agree 100% ;) Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: Unbound in base
Penned by Jan Klemkow on 20120217 3:38.24, we have: | There is an other problem with replacing bind with unbound and nsd. | If you have a setup where you need to do authoritative and recursive | resolving of domains with the same socket and you have to synchronise | with an extern dns server over zone transfers. | | This setup is not possible at the moment with unbound and nsd. | You need a feature in unbound that it forwards zone transfer requests | to another dns server. | | I think it could be possible with the unbound python-extension to | implement such a feature, but in OpenBSD Base there will no unbound | with this kind of extension. | | I think we need modern bind in ports if we do the replacement. So that | the admins out there could easily use OpenBSD as a DNS-Server with such | extra features. | -- | Jan Klemkow I have totd resolving from unbound which gets some info from nsd on the same system. (yes, I should try Ryan's DNS64 unbound diff...) It is quite possible, you simply need to configure the various daemons to see each other at alternate ports and let the recursive be port 53. If you think you need both recursive and authoritative on the same IP and port 53, then you miss the point of the separation. You can still accomplish this by using pf to redirect traffic based on the need for recursion vs authoritative service, aka local systems tend to need recursion while remote only need to see authoritative... but it is arguably simpler to just use a different IP for each. Thanks, -- 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) | 2525 NW Expy #525, Oklahoma City, OK 73112 \ 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: Unbound in base
On Fri, Feb 17, 2012 at 12:01:46PM +0100, Henning Brauer wrote: * Jan Klemkow j.klem...@wemelug.de [2012-02-17 10:45]: There is an other problem with replacing bind with unbound and nsd. If you have a setup where you need to do authoritative and recursive resolving of domains with the same socket and you have to synchronise with an extern dns server over zone transfers. I see no reason to support or even remotely take such a stupid setup into consideration. On 2012/02/17 13:18, Jan Klemkow wrote: I was working on replacing bind with unbound and nsd a half year ago. I run into this problem. I think in local networks you get such setups where you have to serve clients with global request like google.de and local requests like mail.inhouse.company.com. I just want to hint this problem. In my opinion the replacement of bind with unbound and nsd is more important than the support for this kind of setups :-) I don't see why there's a need to synchronise with an extern dns server over zone transfers for this, I haven't seen a sane setup where local-zone and forward-zone aren't enough for this side of things. (note you may need 'nodefault' if you want to override the as112 reverse zones). Views are a different matter but they don't tend to get used very much in sane setups either ;)
Re: Unbound in base
use the stub syntax in unbound. Penned by Jan Klemkow on 20120217 6:18.33, we have: | I was working on replacing bind with unbound and nsd a half year ago. | I run into this problem. I think in local networks you get such setups | where you have to serve clients with global request like google.de and | local requests like mail.inhouse.company.com. | | I just want to hint this problem. | In my opinion the replacement of bind with unbound and nsd is more | important than the support for this kind of setups :-) | | On Fri, Feb 17, 2012 at 12:01:46PM +0100, Henning Brauer wrote: | * Jan Klemkow j.klem...@wemelug.de [2012-02-17 10:45]: | There is an other problem with replacing bind with unbound and nsd. | If you have a setup where you need to do authoritative and recursive | resolving of domains with the same socket and you have to synchronise | with an extern dns server over zone transfers. | | I see no reason to support or even remotely take such a stupid setup | into consideration. | | -- | 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/ | | | -- | Jan Klemkow -- 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) | 2525 NW Expy #525, Oklahoma City, OK 73112 \ 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: Unbound in base
* Bjvrn Ketelaars bjorn.ketela...@hydroxide.nl [2012-02-15 06:48]: 2.) Testing (read: does it compile and work) on AMD64. amd64 is easy, better questions are things like does it build/work on vax (gcc2, no shared libs), does it work on unusual arch like hppa, etc. I agree, however I cannot help with these arches as I do not have access to them. Anyone does? I tested another arch, alpha with -current from 2012-02-12. A couple of build scripts needed executable bits to build successfully, like install-sh and libtool (hppa had the same issue, of course, forgot to mention that). Other than that, it works fine. Cheers, Ralf
Re: Unbound in base
On 2012/02/15 09:54, Gregory Edigarov wrote: On Tue, 14 Feb 2012 15:48:49 -0500 Brad Smith b...@comstyle.com wrote: On 14/02/12 3:17 PM, roberth wrote: On Mon, 13 Feb 2012 22:35:15 +0100 Bjvrn Ketelaarsbjorn.ketela...@hydroxide.nl wrote: How and when do we automatically generate unbound-control keys? if so, where should that be done? Simply don't bother? rndc keys aren't setup automagically either. The daemon will work just fine without it, let it be up to the admin who wants to use it. Not an option with 5.1/-current. You now need it for the rc.d script to work properly. why is that again? Because it calls unbound-control to stop the daemon, we need to add an rc_pre section and change the default config to handle this. Unfortunately it wasn't noticed/reported before lock.
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: m...@openbsd.org m...@openbsd.org; tech@openbsd.org tech@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, 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: m...@openbsd.org m...@openbsd.org; tech@openbsd.org tech@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
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, 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
On Mon, 13 Feb 2012 22:35:15 +0100 Bjvrn Ketelaars bjorn.ketela...@hydroxide.nl wrote: How and when do we automatically generate unbound-control keys? if so, where should that be done? Simply don't bother? rndc keys aren't setup automagically either. The daemon will work just fine without it, let it be up to the admin who wants to use it.
Re: Unbound in base
On Tue, Feb 14, 2012 at 9:17 PM, roberth rob...@openbsd.pap.st wrote:
On Mon, 13 Feb 2012 22:35:15 +0100
Bjvrn Ketelaars bjorn.ketela...@hydroxide.nl wrote:
How and when do we automatically generate unbound-control keys? if
so, where should that be done?
Simply don't bother?
rndc keys aren't setup automagically either.
The daemon will work just fine without it, let it be up to the admin
who wants to use it.
For basic operation (read: local starting and / or stopping of the
daemon) the use of unbound-control is not necessary. One could use
/etc/rc.d/unbound for this. However, for the neat stuff [1] one needs
unbound-control and therefore signed keys.
Concerning rndc and generating shared secret. This is done by the
system startup script run by init on autoboot or after single-user.
From /etc/rc:
if [ X${named_flags} != XNO ]; then
if ! cmp -s /etc/rndc.key /var/named/etc/rndc.key ; then
echo -n rndc-confgen: generating shared secret...
if rndc-confgen -a -t /var/named /dev/null 21;
then
chmod 0640 /var/named/etc/rndc.key \
/dev/null 21
echo done.
else
echo failed.
fi
fi
fi
The option is there, it is easy to implement and is easy to use. So,
why not make it default?
[1] http://www.rootr.net/man/man/unbound-control/8
--
Bjvrn Ketelaars
Re: Unbound in base
On 14/02/12 3:17 PM, roberth wrote: On Mon, 13 Feb 2012 22:35:15 +0100 Bjvrn Ketelaarsbjorn.ketela...@hydroxide.nl wrote: How and when do we automatically generate unbound-control keys? if so, where should that be done? Simply don't bother? rndc keys aren't setup automagically either. The daemon will work just fine without it, let it be up to the admin who wants to use it. Not an option with 5.1/-current. You now need it for the rc.d script to work properly. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Unbound in base
On 14/02/12 3:38 PM, Bjvrn Ketelaars wrote: On Tue, Feb 14, 2012 at 9:17 PM, roberthrob...@openbsd.pap.st wrote: On Mon, 13 Feb 2012 22:35:15 +0100 Bjvrn Ketelaarsbjorn.ketela...@hydroxide.nl wrote: How and when do we automatically generate unbound-control keys? if so, where should that be done? Simply don't bother? rndc keys aren't setup automagically either. The daemon will work just fine without it, let it be up to the admin who wants to use it. For basic operation (read: local starting and / or stopping of the daemon) the use of unbound-control is not necessary. One could use /etc/rc.d/unbound for this. Not with 5.1/-current. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Unbound in base
2.) Testing (read: does it compile and work) on AMD64. amd64 is easy, better questions are things like does it build/work on vax (gcc2, no shared libs), does it work on unusual arch like hppa, etc. I agree, however I cannot help with these arches as I do not have access to them. Anyone does? What to do with the BIND tools (dig/host/nslookup)? I don't think drill is quite a sufficient replacement for dig yet, and the other tools are certainly still used and I'd expect to find them in the base OS. So at this point I think they should stay. Clear on this point! I will loo 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. This is tricky! Using unbound-anchor - as a function of unbound_flags (rc.conf) and some 'magic' in the unbound rc.d-script - is the easy part. It is possible to use 'auto-trust-anchor-file' (unbound.conf) as default. However, when there is no anchor-file a built-in value is used. Not a pretty solution. Now the hard part: How do we make unbound.conf listen to unbound_flags (rc.conf)? Any ideas or alternative solutions? -- Bjvrn Ketelaars
Re: Unbound in base
On Tue, 14 Feb 2012 15:49:37 -0500 Brad Smith b...@comstyle.com wrote: On 14/02/12 3:38 PM, Bjvrn Ketelaars wrote: On Tue, Feb 14, 2012 at 9:17 PM, roberthrob...@openbsd.pap.st wrote: On Mon, 13 Feb 2012 22:35:15 +0100 Bjvrn Ketelaarsbjorn.ketela...@hydroxide.nl wrote: How and when do we automatically generate unbound-control keys? if so, where should that be done? Simply don't bother? rndc keys aren't setup automagically either. The daemon will work just fine without it, let it be up to the admin who wants to use it. For basic operation (read: local starting and / or stopping of the daemon) the use of unbound-control is not necessary. One could use /etc/rc.d/unbound for this. Not with 5.1/-current. why is that?
Re: Unbound in base
On Tue, 14 Feb 2012 15:48:49 -0500 Brad Smith b...@comstyle.com wrote: On 14/02/12 3:17 PM, roberth wrote: On Mon, 13 Feb 2012 22:35:15 +0100 Bjvrn Ketelaarsbjorn.ketela...@hydroxide.nl wrote: How and when do we automatically generate unbound-control keys? if so, where should that be done? Simply don't bother? rndc keys aren't setup automagically either. The daemon will work just fine without it, let it be up to the admin who wants to use it. Not an option with 5.1/-current. You now need it for the rc.d script to work properly. why is that again? -- With best regards, Gregory Edigarov
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 2012/02/13 22:35, Bjvrn Ketelaars wrote: 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: 2.) Testing (read: does it compile and work) on AMD64. amd64 is easy, better questions are things like does it build/work on vax (gcc2, no shared libs), does it work on unusual arch like hppa, etc. 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. I don't think drill is quite a sufficient replacement for dig yet, and the other tools are certainly still used and I'd expect to find them in the base OS. So at this point I think they should stay. 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. 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.
