|
Executive Summary: Apostolos Fotakelis shares best practices for running a secure DNS environment, which he’s compiled in his experience as a Microsoft Windows systems administrator. |
DNS wasn’t exactly designed with security in mind, and no one is more aware of this than Apostolos Fotakelis, a systems administrator with NATO in Albania. Apostolos, a regular contributor to Windows IT Pro’s Reader to Reader section, compiled a set of DNS best practices based on his DNS experiences over the past 11 years he’s been in IT, including a stint as systems administrator at Aristotle University of Thessaloniki, Greece. Recently Apostolos and I discussed the techniques he uses for making DNS more secure and some examples from his experiences troubleshooting problems related to name resolution.
Q: What sort of environment are you supporting?
A: For security reasons, I can’t describe our infrastructure \[at NATO\], so I’ll talk about my previous environment at the university instead.
We had eight servers. Initially they ran Linux, IRIX, Solaris, and Windows NT 4.0, but gradually we moved mainly to Windows Server 2003 R2, while preserving two servers running Linux. One of the Linux servers was virtualized. Also we had a ninth Windows 2003 server that was used for some short-term research needs and became live only when needed. In July 2007, we installed a Windows Server 2008 Beta 3 server at one of our sites for testing purposes. The number of end users and workstations varied over time from 50 to 100, depending on our research projects in progress. The clients were running 32- and 64-bit Windows XP. Our main site was on \[the university’s\] campus, and there were two other sites with research labs. The main applications included both Microsoft Office tools (Word, Excel) and our own software and tools for digital watermarking, digital video processing, and artificial intelligence projects.
Q: DNS is a perennial topic of interest for many of our readers, since it’s an essential part of their jobs. What are some DNS best practices you’ve developed over the years?
A: Generally, I always pay special attention to name resolution (mainly DNS, not so often WINS), since it’s something that every infrastructure relies on. When name resolution doesn't work perfectly, it causes numerous problems that sometimes don’t even point to name-resolution problems. So you need to make sure DNS/WINS is set up correctly before you can deal with other Windows IT issues, such as Active Directory and security.
Over time, I’ve developed a DNS best practices list that I always check when setting up a network (see the sidebar “A Sysadmin’s DNS Best Practices List”). Initially I followed Microsoft’s DNS recommendations, then tried some other approaches as well. My DNS resources have been Microsoft TechNet, various forums, and personal experimentation. Also, as a Microsoft Certified Trainer (MCT), I’ve been lucky enough to have taught some smart students who asked me questions that required me to dig even further into DNS, and I also learned from troubleshooting the DNS problems that they faced in their environments. I’ve found these DNS best practices to be applicable for the vast majority of the companies and organizations I’ve worked with.
Q: What are some examples of unusual network behavior you’ve seen that have turned out to be name-resolution problems?
A: Well, usually big delays when opening shared folders on the network indicate such problems, but unfortunately there are also cases where the problem remains well hidden. For example, once I had a client whose Microsoft Exchange server logged numerous errors in the event log without giving any clue that would point to name resolution. It turned out to be a Global Catalog server wrongly registered in DNS; however, we lost many hours trying to troubleshoot the problem.
Testing name resolution is easy but usually isn’t the first thing that comes to mind when you’re troubleshooting problems. My experience so far has shown that unexplainable delays in a LAN usually are either name resolution or RPC (remote procedure call)–related, so I try to test these things first before moving to higher-level troubleshooting.
Q: What are some other challenges your IT department faces in supporting your end users, especially with networking and security?
A: Our needs at Aristotle University of Thessaloniki generally were not vastly different from those of a business environment. From an IT point of view, we faced the same demands for availability, reliability, and security. However, there were also some special needs. For example, when we needed an ERP program, we couldn’t find one on the market that met our needs, so we had to develop our own. Also, many of our applications were for research purposes. That is, they were still under development and usually not well documented, so when you had a problem with an application, you couldn’t expect to find any help on the Internet. All these special needs had a direct effect on security: Since there was no official provider to release patches and updates, you had to act proactively and do in-depth searches when dealing with software security issues.
Another challenge was that sometimes users needed a program that was developed for another platform and didn’t run on Windows XP. In that case, Microsoft Virtual PC was a godsend. Formerly we had dedicated computers for such programs, but with Virtual PC, we just stored the Virtual PC images on DVDs and deployed them to the users that needed the programs.