NETWORK ARCHITECTURE
Any time an organization connects to the Internet, great care has to be taken. For each service that you provide either to or from the Internet, consider the risks carefully.
There are several questions you need to answer before you can decide on a network architecture:
Do I want to maintain a separate, internal DNS?
How much information should I reveal about my internal network?
Must I maintain the primary DNS server, or should I let the ISP do it?
How critical is uptime?
How much traffic will I be generating?
Answering these questions before implementing a DNS design will ensure that your design meets your needs and lasts you several years to come. A common configuration, as illustrated in Figure 12-7, places an external DNS server in the nonsecure demilitarized zone (DMZ) and a separate, internal DNS server behind the corporate firewall.
SECURITY CONSIDERATIONS Anything that is connected to the Internet is a security risk. This includes DNS servers. Several bad things can happen when a DNS server is on the public Internet:
It could be the victim of a denial of service attack, which could render your network unreachable via domain names.
It could be modified so that your domain names resolve to IP addresses outside of the realm of control of your administrators.
If the DNS server is connected to both the public Internet and your private network, it could be used as a launching point for attacks against your internal network if compromised.
With these points in mind, read through the rest of the network architecture section. Security is a critical consideration when designing a network.
DESIGN SUGGESTIONSM Most corporate networks that connect to the Internet have both internal and external portions. The external portion may be used by people on the public Internet and by users within your corporate network. This area of the network is also called the DMZ (demilitarized zone).
There are several different ways in which DNS may be implemented in your network. One method is to place the DNS server outside of your corporate network, so that people on the Internet and in your intranet may reach it. Another possibility is locating the server strictly within your network where it may serve only internal customers.
CONFIGURING AN EXTERNAL DNS SERVER To allow users on the public Internet to reach your DNS server, place it on your external network. There are a couple of reasons you may want to do this:
If you wish to provide primary or secondary DNS services for your own organization
If users are supposed to have access to your internal network from the Internet (for example, telecommuters)
This is not a simple configuration to implement! Great care should be taken with public DNS servers because they are a common point of attack. For example, it is possible for a malicious hacker to attack your public DNS server and replace the IP addresses given for specific hosts with IP addresses on other networks! This would allow them to direct users connecting to your Web site to an entirely different server.
A typical network with an external DNS server looks like the diagram shown in Figure 12-8.
CONFIGURING AN INTERNAL DNS SERVER There are several reasons to configure a separate DNS server for the inside of a corporate network. First, you may not want the entire Internet to know the names and IP addresses of all the systems within your organization. However, you almost certainly want internal users to be able to gain access to them. Creating a separate internal DNS server allows you to have this compromise between security and accessibility.
Typically, organizations that host separate internal and external DNS servers allow their ISPs to perform name services for their domains. This type of configuration is shown in Figure 12-9.
Capacity Planning and Performance
In smaller companies, DNS servers may never become overloaded. However, in larger organizations or companies that host busy DNS servers (such as Internet service providers), planning the capacity needs of DNS servers is an important consideration. Fortunately, as with all things Microsoft, there are several ways to monitor and anticipate performance requirements.
USING DNS MANAGER
The simplest way is to use the Microsoft DNS Manager that is added to the Administrative Tools folder when DNS services are installed on an NT Server. The information provided by this dialog box is minimal but sufficient for getting a mile-high view of the overall usage of a particular system. Figure 12-10 shows the Server Statistics page of the DNS Manager of a very quiet DNS server.
The DNS Manager is a simple and limited performance analysis tool, providing only a raw listing of the number of queries and responses provided. However, it is useful for determining whether the majority of the queries and responses are happening through UDP or TCP or are being forwarded to a WINS server. The limited amount of information is somewhat frustrating, because there are no Performance Monitor counters specifically for DNS.
Because TCP is used only when UDP queries fail, high numbers of TCP queries in relation to UDP queries can indicate to you that DNS queries are operating inefficiently. If a large number of the total queries are being forwarded to a WINS server, consider a more efficient method. Forwarding queries to a WINS server more than doubles the amount of traffic normally incurred by a DNS query and roughly triples the total latency.
USING PERFORMANCE MONITOR
A more powerful alternative to the DNS Manager is the Performance Monitor, which I refer to throughout this book. Unfortunately, Microsoft has not provided Performance Monitor objects specifically for the DNS service. However, the standard suite of objects are there and, in conjunction with the DNS Manager, sufficient for capacity planning.
Start performance analysis and capacity planning in the same way you would for any system, by monitoring counters for processor, memory, and network utilization. If the system is not a dedicated DNS server, add the following counters to help you separate utilization caused by DNS:
Process object, % Processor Time counter, DNS instance: This counter reveals how much of the total CPU time is being consumed by the DNS service. If your DNS server is performing other tasks as well, this will allow you to determine if the DNS process or something else causes high processor utilization. If you see that your server is busy overall but the DNS process shows very low utilization, monitor the performance of other processes to find the culprit.
Process object, Page Faults/sec counter, DNS instance: This counter tells you how bad the DNS process is hammering your system’s memory. If the number of page faults caused by DNS increases, it is a good indicator that you should add more memory or transfer DNS responsibilities to a different, dedicated server.
LOAD BALANCING
Large networks or those with heavy DNS usage may need to split the responsibilities between multiple servers. If configured correctly, such a system has the advantage of providing fail-over capabilities as well. For this reason, DNS services should always be split between two servers, no matter how small the network. Take this minimal requirement into consideration when planning a DNS structure. As the size of a network increases, you can split the load between an increasing number of servers.
For more information on load balancing, read the section under Planning for Load Balancing earlier in this chapter.
Integrating into Your NT Infrastructure
As if it wasn’t confusing enough that Microsoft refers to their administrative model as a domain, now you have to worry about integrating NT domains into the Internet domains, and vice-versa. This is a difficult concept to read about, much less write about. Nonetheless, how your Internet domains fit into your NT domains is an important consideration.
In versions of Windows NT 3.51 and earlier, native DNS support was limited to the client-side protocol only. Starting with Windows NT 4.0, a DNS server is provided as part of the operating system. As I have stated earlier in the book, NT 4.0 provides greater support for using DNS names instead of WINS names, an indication of the future direction of the operating system.
Up to this point, however, DNS has not been a critical part of a Microsoft network. If you wanted to use it for compatibility with UNIX hosts or the Internet, you had that option. Nonetheless, Internet domain design did not relate to the way NT domains were designed; the two operated completely independent of each other. All of this is changing, and quickly.
MODELING DNS ARCHITECTURE AFTER DOMAIN ARCHITECTURE
NT 5.0 will incorporate the Enhanced Directory Services, which will integrate tightly with DNS. Exactly how this will work is still somewhat uncertain, but there are guidelines to follow, if you are creating a new NT domain, that will make the migration simpler.
First, make a strong effort to use a single model for both your NT domains and your Internet domains. For example, consider how you would structure your DNS in an NT domain based on the NT master domain model. If you had created a separate resource domain for each remote office and a single user domain, an excellent way to design your Internet domains would be to acquire a second-level domain, such as mycompany.com. Then, you would create a subdomain that corresponded to each NT domain.
It will make your life easier both in the present and in the future with NT 5.0 if the name of the NT domain corresponds to the name of the Internet domain (or subdomain, for multiple-domain designs). For example, if your organization is called MyCompany and has the domain name mycompany.com, the PHOENIX NT domain should correspond to the phoenix.mycompany.com Internet domain. In this way, both NT and Internet domains share the same hierarchy.
In the future, when NT systems are organized by Internet domain names, minimal reorganization will be necessary. Furthermore, systems will be named logically, allowing people in an Internet domain to abbreviate the names of the systems nearest to them. To clarify with an example, if a user on a system named northrup.west.mycompany.com wanted to Telnet to the local mail server called pop.west.mycompany.com, the user would merely have to issue the command telnet pop. Grouping systems logically within Internet domains simplifies the lives of all your users because Windows NT allows FQDNs to be abbreviated with hostnames when accessing systems in the same domain.
INTEGRATING DHCP, WINS, AND DNS
If you are already using WINS (Windows Internet Naming Service) and DHCP (Dynamic Host Configuration Protocol) together and wish to add DNS, make a point of integrating the three together. Really, you only need to integrate WINS and DNS together, since DHCP and WINS are probably already configured on your network. By integrating these services, clients that are assigned an IP address during startup may also be referenced on the network using a domain hostname.
This may seem simple enough; after all, DNS and WINS are just alike, right? If you’ve read this far, you already know better than that. Nonetheless, it is a common misconception. They perform similar functions but operate entirely differently.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
