FYI: Slightly rough MaraDNS default installation on Ubuntu
Rick Moen
rick at linuxmafia.com
Fri Aug 22 15:50:09 EDT 2008
MaraDNS keeps coming up in _Linux Gazette_ magazine's efforts to stay on
top of the Kaminsky affair and its ramifications for Linux users. I'm
one of the _Gazette's_ editors; Ben Okopnik (cited below) is editor in
chief. I kept telling Ben that running a reliable local
recursive-resolver nameserver should be essential to all small networks
including his, and that setting one up is dead-simple. Right at
publication deadline for the August issue, Ben disagreed. The
below-cited, hurried e-mail exchange followed, where I test-installed
each of MaraDNS, BIND9, and PowerDNS Recursor on an Ubuntu workstation.
Ubuntu have not yet acted on the bug I filed for their MaraDNS package
(but at lest they didn't close it ;-> ).
In case anyone's interested, herewith, my page of rundowns on
DNS-related software for Linux:
"DNS Servers" on http://linuxmafia.com/kb/Network_Other/
----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----
Date: Sun, 3 Aug 2008 18:31:21 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Ben Okopnik <ben at linuxmafia.com>
Subject: MaraDNS default installation (was: pdnsd)
Quoting Ben Okopnik (ben at linuxmafia.com):
> Rick, I've been researching and experimenting, and that statement of "no
> muss, no fuss, no greasy aftertaste" for DNS RR server installation may
> have been a bit too optimistic. BIND9, MaraDNS, and PowerDNS all fail
> the "turnkey" test;
Again, this is a from-scratch package install on Ubuntu Gutsy Gibbon:
~$ sudo apt-get install maradns
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
maradns
0 upgraded, 1 newly installed, 0 to remove and 254 not upgraded.
Need to get 479kB of archives.
After unpacking 1139kB of additional disk space will be used.
[snip package fetch]
Fetched 479kB in 0s (9016kB/s)
Selecting previously deselected package maradns.
(Reading database ... 135280 files and directories currently installed.)
Unpacking maradns (from .../maradns_1.2.12.08-1_i386.deb) ...
Setting up maradns (1.2.12.08-1) ...
creating MaraDNS system user...
adduser: Warning: that home directory does not belong to the user you
are currently creating.
Starting maradns: maradns.
Starting zoneserver: No zone ACL's configured for /etc/maradns/mararc --
not starting zoneserver for it.
zoneserver.
I belive you gave up upon seeing that message about zoneserver ACLs, but
ironically _that_ was OK. That merely meant that MaraDNS wasn't going
to be able to do authoritative service -- which we don't _want_ it to.
However, there were other problems:
First, find out the homedir MaraDNS user, since we'll need it later:
~$ grep maradns /etc/passwd
maradns:x:113:123::/etc/maradns:/bin/false
And what's the ownership of the conffile directory?
$ ls -l /etc/maradns/
total 12
-rw-r--r-- 1 root root 10311 2007-09-19 03:11 mararc
Last, is the recursive-resolver daemon _working_?
$ dig linuxmafia.com @localhost +short
;; connection timed out; no servers could be reached
$
So, oops, the recursive service simply doesn't work, out of the box.
We then have to find out why, and fix it:
/var/log/daemon.log includes:
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS OR
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: POSSIBILITY OF SUCH DAMAGE.
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc:
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: To not display this message, add the follwing to your mararc file:
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc:
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: hide_disclaimer = "YES"
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc:
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Root directory changed
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Binding to address 127.0.0.3
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Socket opened on UDP port 53
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Root privileges dropped
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: All RRs have been loaded
~$ dig linuxmafia.com @127.0.0.3 +short
;; connection timed out; no servers could be reached
(My recollection was that all IP addresses in the loopback network were
interchangeable, but I just wanted to make sure.)
/usr/share/doc/maradns/README.Debian starts out with:
maradns for Debian
------------------
This version of MaraDNS works as authoritative or/and recursive server.
Below are guides to two typical setups:
Recursive:
----------
Usually good enough to:
sudo cp /usr/share/doc/maradns/en/examples/example_recursive_mararc.txt /etc/maradns/mararc
BUT please use the uid and gid of the default mararc. Look up the
maradns uid and gid with `id`.
You might want to throw in:
hide_disclaimer = "YES"
And use icann root servers instead.
[...]
~$ id maradns
uid=113(maradns) gid=123(maradns) groups=123(maradns)
(Actually, we already knew that from when I looked up that user's
homedir.)
After following the above ("sudo cp") advice, including making sure the
following lines were in /etc/maradns/mararc:
# The numeric UID MaraDNS will run as
maradns_uid = 123
# Recursive ACL: Who is allowd to perform recursive queries.
recursive_acl = "127.0.0.0/8"
hide_disclaimer = "YES"
I did:
$ sudo /etc/init.d/maradns start
Starting maradns: maradns.
$ dig linuxmafia.com @localhost +short
198.144.195.186
Yay, works as intended.
(It was not necessary to give the maradns user or group ownership over
/etc/maradns/ .)
So, indeed it wasn't _quite_ turnkey, and could use a bit of improvement
from the package maintainer to optimise for the most common case. The
package maintainer might have two objections, if I were to so suggest:
1. "The target audience can take care of such things, because the target
audience are sysadmins." Which is where we get the chicken-and-egg
problem of regular users never running their own caching nameservers
because it's too difficult, and package maintainers never bothering to
remove the difficulty because regular users don't use the software.
2. "The MaraDNS package includes two separate daemon processes, the
recursiver-resolver daemon and the zoneserver, with separate
configuration needs. Some people will need one function but not the
other; some will need both. So, there's no such thing as an optimised
configuration for the most common case."
There would be some justice to that -- but I frankly don't think it'd be
difficult to ask the user a few questions, construct a mararc file to
suit, and only _then_ start the daemon(s).
Not surprisingly, there is not yet an Ubuntu package for "Unbound" -- at
least, not in Gutsy Gibbon. (In fact, it appears to be present only in
the Intrepid Ibis beta.)
That leaves only PowerDNS Recursor and dnscache (from djbdns). Gutsy
Gibbon has package "djbdns-installer - Source only package for building
djbdns" (reflecting the pre-"public domain" status of the djbdns 1.06
source code at the time the package was put together).
To my surprise, there's a pdns-recursor package:
Description: PowerDNS recursor
PowerDNS is a versatile nameserver which supports a large number
of different backends ranging from simple zonefiles to relational
databases and load balancing/failover algorithms.
PowerDNS tries to emphasize speed and security.
.
This is the recursive nameserver that goes out to the internet and
resolve queries about other domains.
I'll try that one, and then probably call it quits -- until the Ubuntu
folks catch up with the licence change on djbdns, and re-packages it to
get around a number of problems that will suddenly be fixable (if anyone
still cares): I hear that among the problems with default djbdns is
that it needs an immediate source-level security patch, plus you need to
fetch the current named.root file from ftp.internic.net , as the one
provided is out of date.
And, even after that, it's my understanding that djbdns has problems
resolving some domains (such as Akamai). There may or may not be
suitable patches, and I can either gamely try to chase down that sort of
stuff or just say to myself "Screw it. Nobody should have to go to that
sort of trouble, and desktop users sure ain't going to."
----- End forwarded message -----
----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----
Date: Sun, 3 Aug 2008 19:49:59 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Ben Okopnik <ben at linuxmafia.com>
Subject: Re: (forw) MaraDNS default installation (was: pdnsd)
Quoting Ben Okopnik (ben at linuxmafia.com):
> Yes. The target _audience_ may well be sysadmins, but the _target_ is
> every user. Unless things are fixed at that level - e.g., the
> maintainers getting that point totally clear in their heads - we're
> screwed, and Dan K's exposure of this vuln goes for nothing, except
> maybe to tell the Blackhats where to look (the author of Metasploit said
> that he'd have an exploit for it *that day*.)
That'll be Wednesday. I recall reading, in any event, that Metasploit
sprouted an attack mode for cache poisoning the same day that the German
mathematician posted his blog post.
> Yep. Several packages do exactly that - and in the case of an RR DNS
> server, the questions would be trivial. It would be _very_ nice if you
> could ask "Do you just want a caching server (STRONGLY RECOMMENDED
> UNLESS YOU KNOW ENOUGH TO SAY 'NO')?" and then install 'resolvconf' if
> the answer is 'yes' - but I've never seen that kind of a setup on any
> package before.
See, this is where I've been suggesting that the influence of BIND9 has
been pernicious: It's conditioned most people to think of server-side
DNS as all one big thing. (The Red Hat / Fedora / CentOS people _do_
have, as I mentioned, a specific configuration of BIND9 for just the
functionality you speak of as package "caching-nameserver").
And yeah, I cannot recall having even heard of resolvconf before --
though it does ring a distant bell.
Anyway, at minimum, BIND9 in its default caching mode, and (more
happily) PowerDNS Recursor meet spec -- though that annoying thing that
necessitates "resolvconf" does stand in the way.
Too bad about the teething problems regarding (at least the Ubuntu
package of) MaraDNS: It's the one offering about which I have the
best feelings overall. Sam's design is really good, he does his own
random number generator and string-handling library for security
reasons, he has a history of not making dumb security errors, and he
actively maintains it. I actually have more confidence in him than I do
in the maintainers of PowerDNS -- who _have_ made a number of hideous
security errors in the past.
----- End forwarded message -----
----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----
Date: Tue, 5 Aug 2008 16:17:08 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Ben Okopnik <ben at linuxmafia.com>
Subject: Re: (forw) Re: (forw) MaraDNS default installation (was: pdnsd)
Quoting Ben Okopnik (ben at linuxmafia.com):
> Ya know, I don't want to sound like a broken record, but - a patch
> (perhaps consisting of a properly-configured conffile and a list of
> directories, etc. that should be created) sent to the maintainer of
> MaraDNS
Short of that, I've just filed a bug with downstream (Ubuntu):
https://bugs.launchpad.net/ubuntu/+source/maradns/+bug/255156
I'll mention that to the upstream author, and see if shameless flattery
might motivate him to improve the upstream fit'n'finish.
----- End forwarded message -----
More information about the list
mailing list