[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postfix-users
Subject:    Re: DANE and DNSSEC adoption
From:       /dev/rob0 <rob0 () gmx ! co ! uk>
Date:       2014-02-24 23:10:32
Message-ID: 20140224231032.GC2739 () harrier ! slackbuilds ! org
[Download RAW message or body]

On Mon, Feb 24, 2014 at 10:50:24PM +0100, Patrick Ben Koetter wrote:
> * Viktor Dukhovni <postfix-users@postfix.org>:
> > On Mon, Feb 24, 2014 at 02:36:46PM -0700, LuKreme wrote:
> > > unbound is better than bind for this sort of thing? (I noticed 
> > > freeBSD 10 has switched from bind to unbound, I expect they 
> > > have good reason).
> > 
> > BIND is fine too, but I've not looked at how it is packaged on
> > various systems.  I know that the unbound package typically includes
> > scripts to automatically handle root zone key rollover.  Perhaps
> > modern BIND packages do that also.

As I said in reply to this in the other thread, it is simple. The 
"dnssec-validation auto;" setting initializes the managed-keys 
database using the compiled-in root key. A new root ZSK rollover 
happens automatically.

> Unbound is *said* to be factor 10 times faster.

Yes, I have heard things like this also, but I have not been shown 
the actual tests, so I remain skeptical. :)

I recently addressed this on the dnsmasq mailing list, where I 
pointed out that a user's perception of DNS speed is dependent on 
many different things, most of which are external and beyond your 
control.

It might be possible to design a reasonable speed comparison, but 
will it be relevant to the real world?

> If you are searching for
> resolver only, you are fine with unbound.

Yes, and the unbound folks also have NSD for authoritative name 
service. BIND, OTOH, is an all-in-one DNS implementation, with a
caveat: you really should not have authoritative and recursive 
service in the same named instance, in general.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
[prev in list] [next in list] [prev in thread] [next in thread]