Bug#861910: maradns-deadwood: deadwood is labeled stable by upstream, how about a full package?

[Sam Trenholme]

To ask for better MX record handling in Deadwood is a feature request,
not a bug report. And upstream’s answer is: I’m not going to do that.
Most people should be using their ISPs mail hub to send mail, not a
small virtual server.

The nice thing about open source is that Andreas (or anyone else) is
free to update Deadwood to have better MX support if this is something
which scratches his itch (he can fix the issues with out-of-bailiwick
CNAME record handling while he’s still inspired to do a bunch of work
for free) — but that’s not my itch.

Deadwood’s big advantage of dnamasq is that it allows stuff like “use
slow in house DNS servers to resolve hostname.example.com, but use
8.8.8.8/4.2.2.1/whatever to resolve anything anything else” in a
configuration file (dnsmasq handles that with a special “-S” flag).

— Sam

On Sat, May 6, 2017 at 9:09 AM, Andreas Metzler  wrote:
> On 2017-05-05 Andreas Metzler  wrote:
>> Hello,
>
>> deadwood was released as stable by upstream. However the Debian package
>> only provides a bare-bone binary without infrastructure
>> (init-script/systemd support files). While the package description
>> documents this no reason is given why.
>
> Hello,
>
> I think I have found a reason for not using deadwood. In short I have
> the feeling that it is not optimized for the use-case where it might be
> useful. :-(
>
> I wanted to use deadwood on a vserver with limited resources, handling
> e-mail an WWW, and deadwood seemed to match the requirements:
> * small/tiny
> * recursive
> * caching
>
> However according to deadwood(1) it would perform poorly there since MX
> handling is - eh - suboptimal:
> | please keep in mind that Deadwood is optimized to be used for web
> | surfing, not as a DNS server for a mail hub. In particular, the IPs
> | for MX records are removed from Deadwood's replies and Deadwood needs
> | to perform additional DNS queries to get the IPs corresponding to MX
> | records
>
> OTOH for /web/ /surfing/ I would rather use dnsmasq. I do not see the
> requirement for recursive DNS there and the resources on desktop
> computers used for surfing are not strained, tinyness is not a
> requirement here.
>
> Anyway. Before discovering this I spent some time on packaging deadwood.
> Preliminary patch attached. (Before uploading I'd switch to a customized
> dwood3rc in debian/ instead of patching the upstream version.)
>
> cu Andreas
> --
> And so my quest for a dnscache replacement continued.

Bug#861910: maradns-deadwood: deadwood is labeled stable by upstream, how about a full package?

[Andreas Metzler]

On 2017-05-05 Andreas Metzler  wrote:
> Hello,

> deadwood was released as stable by upstream. However the Debian package
> only provides a bare-bone binary without infrastructure
> (init-script/systemd support files). While the package description
> documents this no reason is given why.

Hello,

I think I have found a reason for not using deadwood. In short I have
the feeling that it is not optimized for the use-case where it might be
useful. :-(

I wanted to use deadwood on a vserver with limited resources, handling
e-mail an WWW, and deadwood seemed to match the requirements:
* small/tiny
* recursive
* caching

However according to deadwood(1) it would perform poorly there since MX
handling is - eh - suboptimal:
| please keep in mind that Deadwood is optimized to be used for web
| surfing, not as a DNS server for a mail hub. In particular, the IPs
| for MX records are removed from Deadwood's replies and Deadwood needs
| to perform additional DNS queries to get the IPs corresponding to MX
| records

OTOH for /web/ /surfing/ I would rather use dnsmasq. I do not see the
requirement for recursive DNS there and the resources on desktop
computers used for surfing are not strained, tinyness is not a
requirement here.

Anyway. Before discovering this I spent some time on packaging deadwood.
Preliminary patch attached. (Before uploading I'd switch to a customized
dwood3rc in debian/ instead of patching the upstream version.)

cu Andreas
-- 
And so my quest for a dnscache replacement continued.
From 42007e215f603b8c46639eb344679bb4a4937afc Mon Sep 17 00:00:00 2001
From: Andreas Metzler 
Date: Sat, 6 May 2017 14:04:14 +0200
Subject: [PATCH] Let deadwood work out of the box,

Listen on 127.0.0.1.
Ship init-script and systemd service file.
Update deadwood package dependencies; depend on systemd-sysv | duende
instead of recommending it since the init-script requires duende.
Patch upstream dwood3rc to run as proxy:proxy with chroot_dir
/var/cache/maradns-deadwood and install the file in
/etc/maradns/deadwood/.
Also ship dwood3rc-all example.
---
 debian/changelog |  14 
 debian/control   |  12 ++-
 debian/maradns-deadwood.dirs |   2 +
 debian/maradns-deadwood.examples |   2 +-
 debian/maradns-deadwood.init | 135 +++
 debian/maradns-deadwood.install  |   1 +
 debian/maradns-deadwood.service  |  19 +
 debian/patches/25_dwood_debdefaults.diff |  28 +++
 debian/patches/series|   1 +
 debian/rules |   3 +
 10 files changed, 209 insertions(+), 8 deletions(-)
 create mode 100644 debian/maradns-deadwood.dirs
 create mode 100755 debian/maradns-deadwood.init
 create mode 100644 debian/maradns-deadwood.service
 create mode 100644 debian/patches/25_dwood_debdefaults.diff

diff --git a/debian/changelog b/debian/changelog
index 1994ca0..8709014 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+maradns (2.0.13-1.3) UNRELEASED; urgency=medium
+
+  * Let deadwood work out of the box, listening on 127.0.0.1:
+- Ship init-script and systemd service file.
+- Update deadwood package dependencies; depend on systemd-sysv | duende
+  instead of recommending it since the init-script requires duende.
+- Patch upstream dwood3rc to run as proxy:proxy with chroot_dir
+  /var/cache/maradns-deadwood and install the file in
+  /etc/maradns/deadwood/.
+- Also ship dwood3rc-all example.
+Closes: #861910
+
+ -- Andreas Metzler   Sat, 06 May 2017 13:50:16 +0200
+
 maradns (2.0.13-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/control b/debian/control
index 564f064..aec93f3 100644
--- a/debian/control
+++ b/debian/control
@@ -53,19 +53,17 @@ Description: complementary server process to TCP functions for MaraDNS
 Package: maradns-deadwood
 Architecture: any
 Depends:
+ systemd-sysv | duende (>= 2.0.09-1), lsb-base (>= 3.0-6)
  ${misc:Depends},
  ${shlibs:Depends}
 Suggests:
  maradns (>= 2.0.09-1)
-Recommends:
- duende (>= 2.0.09-1)
 Enhances:
  maradns (>= 2.0.04-1)
-Description: simple security-focused recursive Domain Name Service server
- This is an experimental build of the deadwood binary, that is MaraDNS'
- recursive domain name server. It will contain support for IPv6. However
- the necessary integration of init scripts and config files will not be
- done.
+Description: a tiny caching recursive Domain Name Service server
+ Deadwood is MaraDNS' recursive domain name server. It supports both DNS
+ recursion and DNS forwarding. Like the authoritative MaraDNS server it
+ does not support DNSSEC.
 
 Package: duende
 Section: admin
diff --git a/debian/maradns-deadwood.dirs b/debian/maradns-deadwood.dirs
new file mode 100644
index 000..c1cdd7b
--- /dev/null
+++ b/debian/maradns-deadwood.dirs
@@ -0,0 +1,2 @@

Bug#861910: maradns-deadwood: deadwood is labeled stable by upstream, how about a full package?

[Andreas Metzler]

Package: maradns-deadwood
Version: 2.0.13-1.2
Severity: wishlist

Hello,

deadwood was released as stable by upstream. However the Debian package
only provides a bare-bone binary without infrastructure
(init-script/systemd support files). While the package description
documents this no reason is given why.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'