Best practices sanity check

[Dawn Connelly]

Okay, there are about a million different lists on the net that say "here
are the best practices". I have some local monkeys that think they can
manage their own DNS environment. Before I sign off on it, I want to put
together a list of the bare minimum that they need to do before I'll let
them shoot themselves in the foot. Does the below list look reasonable?
Personally I would like to be a bit more strict, but I'm trying to be
reasonable. The * ones are non-negotiable.
*1) Do not allow recursion on any externally facing DNS server.
     The reason this is important is that recursion allows someone to use
your DNS server for something other than the function you intend for it.
There are several techniques that can be used to turn an open DNS server in
to an attacking server against any other server. Since externally facing DNS
servers should not be making any legitimate recursive type queries, it's
best to just disable it. The exception to the recursion disabling would be
for localhost (127.0.0.1). That allows the administrator the ability to do
some basic troubleshooting without really opening much of a vulnerability.

*2) Limit dynamic updates to known legitimate sources
     Make sure that there is some type of 'access control list' that lists
legitimate sources for dynamic registration. If dynamic updates are not
being used by a legitimate source, disable that functionality

3) If possible, configure servers to exchange keys before doing zone
transfers. This one is a tad bit paranoid and I don't believe that TSIG is
currently supported my Microsoft so is most likely moot.

*4) Make sure that all domains have a legitimate email address listed in the
resource records. Preferably the SMTP email address will point to a
distribution list rather than a specific person. But the RFC only requires a
legit email...doesn't HAVE to be for a distro.

5) Use reasonable time to lives (TTLs). Try avoiding a null TTL unless there
is a specific reason (such as an impending migration or for things like NTP
servers). Also don't use excessively long TTLs. Generally a week is the
longest you would ever want to have a TTL set for and that would be for
things that very rarely change like MX records. For an extremely dynamic
environment (IP addresses frequently changing), a default TTL of 5 minutes
is normal. For environments that rarely change IP addresses, anywhere from
1-72 hours is normal. The actual TTL variable should be weighed against the
needs of users and the environment.

6) BACK UP YOUR DATA! Seems like it shouldn't need to be said, but it does.
Make sure that you have functional back ups and have a restore plan in place

*7) Always have at *least* two DNS servers that can answer authoritatively
for your domains. If you only have two servers, it would be good to have a
third one on stand by that can quickly replace a server in case of
catastrophic failure. Make sure that the two DNS servers do not have a
common point of failure. They sit behind a different switch, firewall,
router, power supply, etc. Check the path all the way from the server to the
gateway. Ideally you have DNS servers at multiple physical locations and
sitting behind different ISPs.

*8) Make sure your OS and DNS application are patched appropriately.
Periodically scan servers to make sure they are up to standard for both OS
and application.