Unbound in base

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Unbound in base

Björn Ketelaars
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 workb&do not
hesitate to mail me.

Again, what do you guys think?

Kind regards,

BjC6rn


[1] http://marc.info/?l=openbsd-misc&m=132205020820910&w=2
[2] http://marc.info/?l=openbsd-tech&m=132573371521516&w=2
[3] http://marc.info/?l=openbsd-misc&m=132217547525487&w=2

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Stuart Henderson
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 workb&do not
> hesitate to mail me.

Please do. It would be nice to put them on a public server.

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Peter van Oord van der Vlies-4
In reply to this post by Björn Ketelaars
Hello,

Why replacing bind ?

Kind Regards

Peter

----- Oorspronkelijk bericht -----
Van: Bjvrn Ketelaars [mailto:[hidden email]]
Verzonden: Monday, February 13, 2012 10:35 PM
Aan: [hidden email]
<[hidden email]>; [hidden email] <[hidden email]>
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 workb&do not
hesitate to mail me.

Again, what do you guys think?

Kind regards,

BjC6rn


[1] http://marc.info/?l=openbsd-misc&m=132205020820910&w=2
[2] http://marc.info/?l=openbsd-tech&m=132573371521516&w=2
[3] http://marc.info/?l=openbsd-misc&m=132217547525487&w=2

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Gregory Edigarov-2
On Tue, 14 Feb 2012 08:09:16 +0000
Peter van Oord van der Vlies <[hidden email]> 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:[hidden email]]
> Verzonden: Monday, February 13, 2012 10:35 PM
> Aan: [hidden email]
> <[hidden email]>; [hidden email] <[hidden email]>
> 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 workb&do not hesitate to mail me.
>
> Again, what do you guys think?
>
> Kind regards,
>
> BjC6rn
>
>
> [1] http://marc.info/?l=openbsd-misc&m=132205020820910&w=2
> [2] http://marc.info/?l=openbsd-tech&m=132573371521516&w=2
> [3] http://marc.info/?l=openbsd-misc&m=132217547525487&w=2

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Björn Ketelaars
In reply to this post by Stuart Henderson
2012/2/13 Stuart Henderson <[hidden email]>:
...
>> 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 workb&do
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

Reply | Threaded
Open this post in threaded view
|

Re[2]: Unbound in base

Mo Libden
In reply to this post by Gregory Edigarov-2
14 QP5P2QP0P;Q 2012, 12:59 P>Q Gregory Edigarov <[hidden email]>:
> On Tue, 14 Feb 2012 08:09:16 +0000
> Peter van Oord van der Vlies <[hidden email]> 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?

> Yours C. O.

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Peter Hessler
On 2012 Feb 14 (Tue) at 13:23:01 +0400 (+0400), Mo Libden wrote:
:14 QP5P2QP0P;Q 2012, 12:59 P>Q Gregory Edigarov
<[hidden email]>:
:> On Tue, 14 Feb 2012 08:09:16 +0000
:> Peter van Oord van der Vlies <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Oliver Peter-6
In reply to this post by Mo Libden
On Tue, Feb 14, 2012 at 01:23:01PM +0400, Mo Libden wrote:
> 14 QP5P2QP0P;Q 2012, 12:59 P>Q Gregory Edigarov
<[hidden email]>:

> > On Tue, 14 Feb 2012 08:09:16 +0000
> > Peter van Oord van der Vlies <[hidden email]> 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       [hidden email]       0x456D688F

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Henning Brauer
In reply to this post by Peter van Oord van der Vlies-4
* Peter van Oord van der Vlies <[hidden email]> [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, [hidden email], [hidden email]
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/

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

roberth-5
In reply to this post by Björn Ketelaars
On Mon, 13 Feb 2012 22:35:15 +0100
Bjvrn Ketelaars <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Björn Ketelaars
On Tue, Feb 14, 2012 at 9:17 PM, roberth <[hidden email]> wrote:

> On Mon, 13 Feb 2012 22:35:15 +0100
> Bjvrn Ketelaars <[hidden email]> 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}" != X"NO" ]; 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 2>&1;
then
                                chmod 0640 /var/named/etc/rndc.key \
                                    >/dev/null 2>&1
                                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

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Brad Smith-14
In reply to this post by roberth-5
On 14/02/12 3:17 PM, roberth wrote:

> On Mon, 13 Feb 2012 22:35:15 +0100
> Bjvrn Ketelaars<[hidden email]>  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.

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Brad Smith-14
In reply to this post by Björn Ketelaars
On 14/02/12 3:38 PM, Bjvrn Ketelaars wrote:

> On Tue, Feb 14, 2012 at 9:17 PM, roberth<[hidden email]>  wrote:
>> On Mon, 13 Feb 2012 22:35:15 +0100
>> Bjvrn Ketelaars<[hidden email]>  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.

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Björn Ketelaars
In reply to this post by Stuart Henderson
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Gregory Edigarov-2
In reply to this post by Brad Smith-14
On Tue, 14 Feb 2012 15:49:37 -0500
Brad Smith <[hidden email]> wrote:

> On 14/02/12 3:38 PM, Bjvrn Ketelaars wrote:
> > On Tue, Feb 14, 2012 at 9:17 PM, roberth<[hidden email]>
> > wrote:
> >> On Mon, 13 Feb 2012 22:35:15 +0100
> >> Bjvrn Ketelaars<[hidden email]>  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?

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Gregory Edigarov-2
In reply to this post by Brad Smith-14
On Tue, 14 Feb 2012 15:48:49 -0500
Brad Smith <[hidden email]> wrote:

> On 14/02/12 3:17 PM, roberth wrote:
> > On Mon, 13 Feb 2012 22:35:15 +0100
> > Bjvrn Ketelaars<[hidden email]>  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

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Stuart Henderson
On 2012/02/15 09:54, Gregory Edigarov wrote:

> On Tue, 14 Feb 2012 15:48:49 -0500
> Brad Smith <[hidden email]> wrote:
>
> > On 14/02/12 3:17 PM, roberth wrote:
> > > On Mon, 13 Feb 2012 22:35:15 +0100
> > > Bjvrn Ketelaars<[hidden email]>  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.

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Ralf Horstmann-2
In reply to this post by Björn Ketelaars
* Bjvrn Ketelaars <[hidden email]> [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

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Björn Ketelaars
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Unbound in base

Jan Klemkow
In reply to this post by Ralf Horstmann-2
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

12