[8966] in athena10
Re: [Debathena] #1131: NM/dnsmasq possibly makes
daemon@ATHENA.MIT.EDU (Debathena Trac)
Mon Apr 30 12:32:10 2012
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@MIT.EDU>
Cc: debathena@MIT.EDU
To: geofft@MIT.EDU, jweiss@MIT.EDU, jdreed@MIT.EDU, ghudson@MIT.EDU
Date: Mon, 30 Apr 2012 16:32:06 -0000
Reply-To:
Message-ID: <057.be7481270d5244f7bb6366b8d3589832@mit.edu>
In-Reply-To: <042.0b8b38f9403475473d183cf03aa1665a@mit.edu>
Content-Transfer-Encoding: 8bit
#1131: NM/dnsmasq possibly makes debathena-dns-config obsolete
--------------------+--------------------------------
Reporter: geofft | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Precise Release
Component: -- | Resolution:
Keywords: | Upstream bug:
--------------------+--------------------------------
Comment (by jweiss):
Ops installed a caching resolver on all of our linux servers within the
last year. Previously, we'd only had one on a handful of machines (tho
back in the days of servers based on Athena, those always ran one). The
primary reason for this is that we were seeing slowness with things as
simple and interactive as sshing into the server (apparently the server
performs some DNS queries in this case, I think reverse-resolving the
client's IP address). These problems occurred when one of the MITnet DNS
servers was less-than-fully-responsive (which in the few cases I checked
was due to some machine out on the internet hosing it down). So, I
believe that having a caching resolver is generally beneficial.
Additionally, as jdreed points out, it's good to avoid diverging from
upstream.
--
Ticket URL: <https://athena10.mit.edu/trac/ticket/1131#comment:6>
Debathena <http://debathena.mit.edu>
MIT Debathena Project
