[6025] in Release_7.7_team
systemic DNS problems on Athena workstations (solved?)
daemon@ATHENA.MIT.EDU (andrew m. boardman)
Fri Jul 11 22:25:59 2008
Date: Fri, 11 Jul 2008 22:25:21 -0400
Message-Id: <200807120225.m6C2PLhf018927@pothole.mit.edu>
From: "andrew m. boardman" <amb@MIT.EDU>
To: release-team@MIT.EDU
X-Spam-Flag: NO
X-Spam-Score: 0.00
Yesterday I sent mail to netops saying "hey, you turned off TCP
nameservice again and Athena machines are going to be sad. Please fix
it."
Later yesterday I caught up with jis and had a talk about the issues at
hand, and it turned out to be a real problem, which is why I'm now
sending mail to release-team. (The first round of mail was just CC'd to
rel-eng.)
Background: a high-profile security vulnerability was recently
announced against ISC's BIND, and NIST promptly took the required
update. There is, however, some other code included in the update
which is causing problems with the server's use of TCP connections, so
that functionality was shut off.
Athena machines, however, rely on being able to transfer the MIT.EDU
stub zone (via TCP) in order to resolve MIT.EDU addresses. These
transfers were failing for several days, although the timeouts are set
up such that only the very lucky or peculiarly configured would have
seen an actual service disruption.
Somebody In Netops Did Something[tm] and stub zone transfers are working
again, though it's not clear whether the fix is temporary or permanent.
But, since it ended up causing a minor kerfluffle, now y'all know.
Any objections to punting the MIT.EDU stub zone in some future update?
It's not clear to me what it wins us in this day and age, but I may be
missing some subtleties.
