FYI: Slightly rough MaraDNS default installation on Ubuntu
Ken Lyons
kenl at graphixwizard.com
Sat Aug 23 21:32:32 EDT 2008
I have used Ubuntu for production machines for 2 years now,
we started on RH 5.2, moved to Gentoo then to Ubuntu 6.06 lts,
so far Ubuntu has been the best for us.
One issue that we had, like many admins, is that apt-get,
a great tool, doesn't always have the most recent versions of software.
Both MaraDNS and ClamAV have always seemed to be behind...
which is why we just install thoses from the source downloads.
If you download an OLD version apt-get, your going to have many
problems that have already been fixed in newwer versions.
--we had this same issue with Gentoo, but support for Ubuntu seems to be
much better overall.
Ken Lyons
-- from a medium ISP in Orlando
Rick Moen wrote:
> 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