Mailing List Archive

* Michael Marria <mrmarria@gmail.com> [2015-01-29 14:01]:
> After many years running qmail on FreeBSD 6, it's time to upgrade
> I have a new FreeBSD 10.1 ZFS platform set up and see that djbdns may be a
> bit dated for install along side the qmail
> re-install.
> A general best practices response about djbdns and unbind or
> alternatives I haven't thought of?

Well, there's certainly more than one take on it.

I have long given up on dnscache. Too much of a hassle on my feet. I
vaguely remember some issues with some of its stranger behaviours, but
it's too long ago for anything less vague. No DNSSEC.
I switched to unbound, which does the job without annoying me at all.
Just Works. I spent some time with the author auditing the privsep
parts, couldn't find any real mistakes, basically just had stylistic
remarks. Solid DNNSEC.

tinydns is another story. I'm still a big fan of the mmaped cdb
approach. However, a lot of time has passed and what we run today
still looks & feels like tinydns, but is substantially modified.
Thanks to the flexible data format there aren't too many changes, most
of the magic is in the data file generation process instead. The
changes to tinydns itself are few:
-grok & log NOTIFYs
-rotateip
-DNSSEC support, 95% the tinydnssec.org patch
-axfrdns modified to skip the pseudo records the above needs
I don't use tinydns-sign from tinydnssec.org, it is quite horrible and
very incomplete. Unsuitable for big data files, will eat memory for
breakfast. Unusable when you use locations. Bugs in the NSEC3
generation, including one where it'll become a malloc-bomb until
rlimits are reached or the machine swaps itself to death.
Instead, I have written the dnssec processing (generating RRSIGs,
the NSEC3 processing, location handling and the pseudo records) from
scratch, integrated into our data file generation process. There are
several mean pitfalls there, last not least because tinydns doesn't
have a clear concept of a zone, which makes an approach working on
existing data files really hard.
(reminds me that I still haven't poked the tinydnssec author about
these issues, ugh, shame on me)

I'm still very worried about the aplification issues that DNSSEC makes
much worse - I consider that battle lost, and given the choice between
DNSSEC and plain old insecure DNS, I know what I pick. Ymmv.

--
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, VMs/PVS, Application Hosting

On 2015-01-31 21:50, Henning Brauer wrote:
> * Michael Marria <mrmarria@gmail.com> [2015-01-29 14:01]:
>> After many years running qmail on FreeBSD 6, it's time to
>> upgrade
>> I have a new FreeBSD 10.1 ZFS platform set up and see that djbdns
>> may be a
>> bit dated for install along side the qmail
>> re-install.
>> A general best practices response about djbdns and unbind or
>> alternatives I haven't thought of?
>
> Well, there's certainly more than one take on it.
>
> I have long given up on dnscache. Too much of a hassle on my feet. I
> vaguely remember some issues with some of its stranger behaviours,
> but
> it's too long ago for anything less vague. No DNSSEC.
> I switched to unbound, which does the job without annoying me at all.
> Just Works. I spent some time with the author auditing the privsep
> parts, couldn't find any real mistakes, basically just had stylistic
> remarks. Solid DNNSEC.

+1 to unbound we switched over to it some years ago from dnscache, on
the authoritative side we have an internal fork (circa 2006) of mydns
(sql etc which I know is not everybody's thing)

> I'm still very worried about the aplification issues that DNSSEC
> makes
> much worse - I consider that battle lost, and given the choice
> between
> DNSSEC and plain old insecure DNS, I know what I pick. Ymmv.

yep indeed the only suggested recourse seems to be to rate limit DNS
traffic :|, or that it doesn't matter on today's fast networks! hmmm.

Paul

Hi Michael,

(I'm a little late in the discussion here .. ).


On Thu, 29 Jan 2015 05:54:08 -0700, Michael Marria <mrmarria@gmail.com> wrote :

>
> Hey gang
> After many years running qmail on FreeBSD 6, it's time to upgrade
> I have a new FreeBSD 10.1 ZFS platform set up and see that djbdns may be a
> bit dated for install along side the qmail
> re-install.
> A general best practices response about djbdns and unbind or
> alternatives I haven't thought of?


Unlike the other answers, I will not discuss the basic issues of djbdns, but rather focus
on your requirements:

1. Unbound comes with FreeBSD 10.x and replaces Bind. This was certainly a good
choice of the FreeBSD maintainers; though the UI has changed.

2. qmail depends on a qualified cache. Fortunately, qmail is not subject of the glibc
gethostbyname() bug. Thus, you should setup your own cache anyway to speed up name
resolution. Otherwise you depend on your provider's cache.

3. djbdns includes dnscache which will cache even 'unknown' (here: AAAA) records.
Thus, some IPv6 enabled versions of qmail will work with dnscache.

4. In case you require your cache to act as DNSSEC full resolver, dnscache is certainly
the wrong tool. There exist patches however, but certainly qmail is neither well prepared
to deal with DNSSEC zones nor with CurveDNS.

One of my forthcoming tasks is, to go for that.

> Glad to see the discussion of qmail state today and possible re-releases
> with updates. It is a pretty confusing mess out there right now, and
> I'm not inclined to think the ports are inconsistent with each other.
> Thanks for any thoughts.

Given the requirements for DNSSEC and IPv6, running unbound as cache is certainly a
good solution. Take care to increase the UDP buffer limit in qmail to be able to support
large DNS responses.

In case you are setting up FreeBSD 10.x for qmail, you need to patch it; otherwise it will
not work. My Spamcontrol patch includes those changes and will work fine with clang
(so my other SW does as well).


regards.
--eh.


>
> Michael
>
>

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/

On 2015-02-01 12:30, Erwin Hoffmann wrote:

>
> Given the requirements for DNSSEC and IPv6, running unbound as cache
> is certainly a
> good solution. Take care to increase the UDP buffer limit in qmail to
> be able to support
> large DNS responses.
>

quite, and also watch out for CNAME errors that can result from qmail's
ANY queries and poorly implemented authoritative DNS servers!

On Thu, Jan 29, 2015 at 05:54:08AM -0700, Michael Marria wrote:
> A general best practices response about djbdns and unbind or
> alternatives I haven't thought of?

I use qmail with dnscache, including Matthew Dempsky's DNSCurve patch.
My second choice would be unbound. BIND is not an option at all.

Nicolai

Hi Nicolai,



On Sun, 1 Feb 2015 18:24:44 +0000, Nicolai <nicolai-qmail@chocolatine.org> wrote :

> On Thu, Jan 29, 2015 at 05:54:08AM -0700, Michael Marria wrote:
> > A general best practices response about djbdns and unbind or
> > alternatives I haven't thought of?
>
> I use qmail with dnscache, including Matthew Dempsky's DNSCurve patch.
> My second choice would be unbound. BIND is not an option at all.

Thanks for you opinion.

When I've finished my s/qmail release, I will to provide an integrated solution, supporting
Matthew's extension and the IPv6 patch for djbdns.

However, the problem ist not just a technical one:

* In case you run a DNS content server you have to provide something like *trust* and
even more *consistency* to the one, generating the query.

* In case you run a DNS cache, you have to provide the means to testify the trust and the
consistency of answers.

* The final item is: How to convince your sub-resolvers about your answers.

Apart from the underlying technical means, that's a matter of strategy and algorithms
poured-in.


Now coming back to email delivery and reception: Does this play a role? We've seen
fast-flux spamming. We have seen spam from DKIM verified hosts. DNS won't give you a
particular answer to solve this abuse. DNSSEC for example will problem waste a lot of
CPU cycles just to return forged answers which might be syntactical correct, but
nevertheless worthless.

The basic question is (for email): How to provide message confidentially (and transport
delivery availability) to the purported recipient and reduce abuse of the transport
channel.

These are just my thoughts. I hope to provide some (hints for a) solution within my
forthcoming SW developments.

regards.
--eh.



>
> Nicolai
>
>
>

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/

* Erwin Hoffmann <feh@fehcom.de> [2015-02-01 20:47]:
> DNSSEC for example will problem waste a lot of CPU cycles just to
> return forged answers which might be syntactical correct, but
> nevertheless worthless.

oh cut the crap, that is so far from the truth that it's a shame.

The processing cost is signing the zone. RRSIGs and NSEC3 records are
then part of the data set, nothing is calculated per-packet.
There is trivial overhead for including the RRSIGs (and DNSKEY/DS in
some cases), and to find the NSEC3 record in the NXDOMAIN case. That's
it. Neglible.

On the caching resolver side, verifying the RRSIGs is so cheap that it
is neglible as well.

--
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, VMs/PVS, Application Hosting

Thus said Michael Marria on Thu, 29 Jan 2015 05:54:08 -0700:

> A general best practices response about djbdns and unbind or
> alternatives I haven't thought of?

Personal choice really, perhaps dicated by needs. I still use djbdns
(dnscache and tinydns) unpatched.

Andy
--
TAI64 timestamp: 4000000054d03b35

Thus said "Paul Freeman (Core Internet)" on Sun, 01 Feb 2015 12:44:24 +0000:

> quite, and also watch out for CNAME errors that can result from mail's
> qANY queries and poorly implemented authoritative DNS servers!

For this, one should be using:

http://marc.info/?l=qmail&m=134062672511072&w=2#1

This combined with dnscache seems to work fine for me.

One day I should spend some time to investigate dnscache+dnscurve.

Andy
--
TAI64 timestamp: 4000000054d03c45

+1 Andy, so do I.

On Tue, Feb 3, 2015 at 5:05 AM, Andy Bradford <
amb-sendok-1425524754.aaapojogkiabblobfoca@bradfords.org> wrote:

> Thus said Michael Marria on Thu, 29 Jan 2015 05:54:08 -0700:
>
> > A general best practices response about djbdns and unbind or
> > alternatives I haven't thought of?
>
> Personal choice really, perhaps dicated by needs. I still use djbdns
> (dnscache and tinydns) unpatched.
>
> Andy
> --
> TAI64 timestamp: 4000000054d03b35
>
>
>

Well, I am pleased to see the lively responses to this query. I have a lot
to consider. I have a FreeBSD 10.1 system built with DJBDNS as offered by
ports installed, which I am going to have a re-evaluation before installing
the qmail parts. I did an initial qmail install, under 10, which had some
issues with the logs not working correctly, and removed everything to start
fresh after upgrading FreeBSD10 ->> 10.1.

I have some thoughts about the effect of ZFS snapshotting this system as
well, and wonder if anybody has had any good/bad experience with that and
qmail they want to share.

I'll keep watching this discussion as things develop, and Thanks! to
everyone's input!

Michael

On Mon, Feb 2, 2015 at 11:37 PM, Willo van der Merwe <qbitza@gmail.com>
wrote:

> +1 Andy, so do I.
>
> On Tue, Feb 3, 2015 at 5:05 AM, Andy Bradford <
> amb-sendok-1425524754.aaapojogkiabblobfoca@bradfords.org> wrote:
>
>> Thus said Michael Marria on Thu, 29 Jan 2015 05:54:08 -0700:
>>
>> > A general best practices response about djbdns and unbind or
>> > alternatives I haven't thought of?
>>
>> Personal choice really, perhaps dicated by needs. I still use djbdns
>> (dnscache and tinydns) unpatched.
>>
>> Andy
>> --
>> TAI64 timestamp: 4000000054d03b35
>>
>>
>>
>