On Tue, Oct 20, 2009 at 4:37 PM, Tracy Reed <[email protected]> wrote:
> But having learned from the past I am very afraid of taking on any
> such cleanup because that A record which everyone agrees isn't used
> anymore actually serves some hidden critical function.
>
> I am wondering if there are any tools out there which can make this
> easier. For example I am thinking that if I had a way to capture a
> month's worth of DNS traffic and then replay that against the new name
> server and make sure that any queries which returned responses on the
> old setup also returned the same responses on the new server that
> would make things much better.
>
> Does such a tool exist? Is this a good idea? Any better way?

Others have mentioned query logging, which is a great thing and should
help in a quicker way than packet captures.  When we had to attack
this problem at a previous job, we took an iterative outside-to-inside
approach at cleaning things up in small(er) digestible chunks.  IIRC,
it roughly went like this:

1) Fix delegations of sub domains and your zone assignments with your
registrar.  Use a tool like zonecut's DNS Bajaj and other delegation
and zone checkers to find problems and get them addressed.

2) Fix secondary servers and monitor them / ensure zones are never
terribly behind.  Setup ixfer and notifies or take appropriate actions
with your infrastructure tools to ensure secondaries are up-to-date
and redundant (eg: 3 nameservers in the same vmware cluster are not
redundant).

3) Use tools like bind's named-checkzone, nslint, etc.. to walk your
zones and address cruft and warnings.  Chained CNAMES, missing or
incorrect glue records, missing or incorrect reverses, inconsistent or
misleading formatting, wrong serials, etc..there's a ton of stuff that
creeps in over time that can and should be addressed.  Look for places
where techniques like RFC2317 classless delegation can help later on.
Dropping the zone TTL's and RR TTL's is possibly a good idea to do
before doing this work so problems pop up faster.

4)  Do a quick pass to fix/remove the obvious broken things.  The MX
record that points at a dead/gone IP is already broken -- verify that
the IP really is dead and pitch the record.  The RP record that points
at your predecessor's predecessor needs updating.  You'll find a lot
of funk here, including dead/broken apps and configs that will need
fixing.  This will also pop up a lot of questions too, be sure to
record/write these down.

5) Fix up your zone maintenance tools.  If you need to do a huge
cleanup, then there are probably places in your tools that need some
love so these problems don't keep happening.  Minimally, integrate
some of the checking tools/processes you found/used in step 3 above so
that changes are vetted as they checked in or made and rejected if
they don't pass the tests.  Optimally ensure that as much stuff as
possible gets auto-generated (reverses, serials, hostmaster addresses,
etc, etc..).  Adding additional monitoring to capture data on query
rates, etc... is also helpful so you can help correlate problems and
get a better idea of trending.  This is where we did our cutover from
old DNS master server to new, mainly because the tool changes were
sizable enough to make in place upgrades really hard, and we needed to
move to new hardware anyway.

6) At this point you should have a much better DNS infrastructure and
a lot less cruft and noise to cause false positives.  Raise TTL's to a
normal value again, and enable query logging and do a daily compare of
requests versus zone files to see what's not being used and can be
removed, what you may be missing, should be added, etc... This should
also give you some data about setting up views and where they are
needed, moving recursive services, adding local caching name servers
on app servers, etc...

7) Purge, add, fix, enhance, etc... using the data/questions/ideas
from previous steps.

HTH,

-n

-- 
-------------------------------------------
nathan hruby <[email protected]>
metaphysically wrinkle-free
-------------------------------------------
_______________________________________________
Tech mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to