DNS on Windows NT
By Paul Albitz, Matt Larson & Cricket Liu1st Edition October 1998
1-56592-511-4, Order Number: 5114
348 pages, $34.95
|
|
|
|
|
DNS on Windows NTBy Paul Albitz, Matt Larson & Cricket Liu1st Edition October 1998 1-56592-511-4, Order Number: 5114 348 pages, $34.95 |
"What's the use of their having names," the Gnat
said, "if they won't answer to them?"
In this chapter, we'll cover some of the Microsoft DNS Server's more advanced features and suggest how they might come in handy in your DNS infrastructure. (We do save some of the hard-core firewall material 'till the last chapter, though.)
Traditionally, slaves have used a polling scheme to determine when they need a zone transfer. The polling interval is called the refresh time. Other parameters in the zone's SOA record govern other aspects of the polling mechanism.
Wouldn't it be nice if the primary master name server could tell its slave servers when the information in a zone changed? After all, the primary master name server knows the data has changed: every time a zone is changed with DNS Manager, DNS Manager notifies the server, which immediately changes the zone in its memory. The primary's notification could come soon after the actual modification, instead of waiting for the refresh interval to expire.
RFC 1996 proposed a mechanism that would allow primary master servers to notify their slaves of changes to a zone's data. The Microsoft DNS Server implements this scheme, called DNS NOTIFY for short.
DNS NOTIFY works like this: when a primary master name server notices a change to data in a zone, it sends a special notification message to all of the slave servers for that zone. It uses the list of NS records in the zone to build the list of slave servers for the zone. The primary master removes the NS record corresponding to the name server listed in the first field in the zone's SOA record (which by convention lists the name of the primary master name server for the zone), as well as the local host. Removing those name servers prevents the primary master from sending a notification message to itself.
The special NOTIFY request is identified by its opcode in the query header. The opcode for most queries is QUERY. NOTIFY messages have a special opcode, NOTIFY. Other than that, the request looks very much like a query for the SOA record for the zone: it specifies the zone's domain name, class, and a type of SOA.
When a slave receives a NOTIFY request for a zone from one of its configured master name servers, it sends a NOTIFY response. The response tells the master that the slave received the NOTIFY request, so that it can stop sending NOTIFY messages for the zone. Then the slave proceeds just as if the refresh timer had expired: it queries the master server for the SOA record for the zone that the master claimed had changed. If the serial number is higher, the slave transfers the zone.
Why doesn't the slave simply take the master's word that the zone has changed? It's possible that a miscreant could forge NOTIFY requests to our slaves, causing lots of unnecessary zone transfers, amounting to a denial of service attack against our master server.
If the slave actually transfers the zone, RFC 1996 says that it should issue its own NOTIFY requests to the other authoritative name servers for the zone. The idea is that the primary master may not be able to notify all of the slave servers for the zone itself, since it's possible some slaves can't communicate directly with the primary master and so use another slave as their master. However, the Microsoft DNS Server doesn't implement this, and Microsoft DNS Server slaves don't send NOTIFY messages unless explicitly configured to do so.
Here's how that works in practice: on our network, terminator.movie.edu is the primary master for movie.edu, and wormhole.movie.edu and zardoz.movie.edu are slaves. See Figure 10-1.
When we update movie.edu on terminator, terminator sends NOTIFY messages to wormhole and zardoz. Both slaves check to see whether movie.edu's serial number has been incremented and, when they find it has, perform a zone transfer.
Let's also look at a more complicated zone transfer scheme. In Figure 10-2, a is the primary master name server for the zone and b's master server, but b is c 's master server. Moreover, b has two network interfaces.
In this scenario, a notifies both b and c after the zone is updated. b checks to see whether the zone's serial number has been incremented and initiates a zone transfer. However, c ignores a 's NOTIFY message, because a is not c 's configured master name server ( b is). If b is explicitly configured to notify c, then after b's zone transfer completes, it sends c a NOTIFY message, which prompts c to check the serial number b holds for the zone.
Older BIND slave name servers, and other name servers that don't support NOTIFY, will respond with a "Not Implemented" (NOTIMP) error, wait until their refresh timers expire, and transfer the zone then. The Microsoft DNS Server just ignores the NOTIMP error.
NOTIFY is turned off by default and has to be enabled on a zone-by-zone basis. The controls for NOTIFY are accessed via the Notify tab on the Zone Properties window.
Figure 10-3 illustrates the Notify configuration for our old friend the movie.edu zone on the zone's primary, terminator. NOTIFY is enabled simply by listing at least one IP address in the Notify List. The addresses listed, 192.249.249.1 and 192.249.249.9, are for the slaves, wormhole and zardoz. You have to list the IP address of every slave you want to receive a NOTIFY message. Unlike the BIND name server, the Microsoft DNS Server does not use the zone's NS records to determine whom to send a NOTIFY message. You can also enable NOTIFY on a slave if other slaves perform zone transfers from it (a la the complex zone transfer scheme described previously).
We'll talk about the Only Allow Access checkbox in the "Securing Your Name Server" section, later in this chapter.
Our next topic requires a short detour into the world of Microsoft networking. Networks based on NetBT (NetBIOS over TCP) need to perform name resolution, too: hosts need a way to map NetBIOS names [1] to IP addresses. The way this name resolution works has evolved over time. In the early days, hosts would broadcast a query on the LAN to resolve a NetBIOS name. This forced all hosts to listen to every broadcast. Since broadcasts don't leave the local LAN, this method didn't allow name resolution beyond the local subnet. The next evolutionary step was the LMHOSTS file, which is just a list of NetBIOS names and IP addresses. Every host needed an LMHOSTS file to resolve names beyond the local subnet. This model didn't scale very well, either: it was tough to keep the LMHOSTS files up to date and distribute them. The introduction of DHCP essentially made basing a network's NetBIOS name resolution on LMHOSTS files impossible.
DHCP stands for Dynamic Host Configuration Protocol. A detailed description is beyond the scope of this book, [2] but suffice it to say that DHCP eliminates the requirement of configuring a static IP address on every one of your hosts. If those hosts support DHCP, they can contact a DHCP server when they boot to obtain an IP address and other configuration parameters, like the IP addresses of the default router, name servers, and WINS servers.
WINS, which stands for Windows Internet Naming Service, is a Microsoft invention introduced in Windows NT 3.5. The server component of WINS is an implementation of a NetBIOS Name Server as described in RFCs 1001 and 1002. The idea is nothing new--the RFCs date from early 1987. The function of a NetBIOS Name Server is simple: it maps NetBIOS names to IP addresses.
The name and IP address information in a WINS server comes from the various hosts on the network. Once a host sets its IP address using the value sent by a DHCP server, the host registers its name with the WINS server the DHCP server told it about. Actually, any modern NetBT host registers its name with a WINS server, regardless of how it obtained its IP address (dynamically from a DHCP server or statically from a user-input configuration). Modern NetBT hosts also know to contact a WINS server for NetBIOS name resolution, rather than relying on broadcasting or an LMHOSTS file.
So where does DNS fit in to all this? The new name-to-IP address mappings generated when the DHCP server makes IP address assignments aren't visible to DNS. (The traditional DNS update model isn't suited to making incremental changes to zones on the fly, anyway, so it would be difficult to get this information into DNS.) Microsoft realized there would be some value to enabling a DNS Server to query a WINS server, which does know about names for dynamically assigned IP addresses. After all, a NetBIOS name in the WINS server is usually the same as a machine's host name (the first label of its fully qualified domain name in DNS), which is what would be in the DNS Server if there were an easy way to get it there. So a Microsoft DNS Server can be configured to ask a WINS server when it receives a query for a domain name that's not in its zone database.
You may be thinking that a name server contacting a WINS server is kind of silly--isn't there a way for name servers to know what the DHCP servers are doing directly? Yes, and it's coming in NT Version 5. DHCP servers will update name servers after every assignment using the new DNS dynamic update protocol. The importance of WINS in NT 5 is greatly reduced, too. NT 5 hosts will resolve NetBIOS names with DNS rather than WINS. WINS will still be required for a while to support older, legacy clients. But we digress.
WINS Lookup, as it's called, is enabled on a zone-by-zone basis using the WINS Lookup tab of the Zone Properties window. The DNS Server will forward queries for names it doesn't know about to a WINS server for those zones with WINS Lookup enabled. The WINS Lookup configuration for the movie.edu zone on the zone's primary, terminator, is shown in Figure 10-4.
WINS Lookup is enabled by checking the Use WINS Resolution box. The IP addresses of up to five WINS servers go in the WINS Servers field. The DNS Server will try them in the order listed.
By default, the WINS Lookup configuration you establish on the primary master takes effect on the slaves as well. The primary master inserts a special WINS record that gets transferred with the rest of the zone to the slaves. If the slaves are Microsoft DNS Servers, they understand the WINS record and perform WINS lookups accordingly. If the slaves are BIND name servers, they complain about the unknown WINS record. You can suppress sending this WINS record to the slaves by checking Settings only affect local server.
The WINS Lookup window looks slightly different on the slave, as shown in Figure 10-5.
Settings only affect local server has changed to Override Settings From Primary. Checking this box does just what you'd think: if the slave has received WINS lookup configuration from the primary, you can override it by checking this box.
The Advanced button produces the same window, shown in Figure 10-6, for either the primary master or a slave.
Submit DNS Domain as NetBIOS Scope is applicable only if you're using NetBIOS scope in your network. If you are, and if your scope names correspond to DNS domain names, you can pass along the DNS domain name (for example, movie.edu) along with the host name to the WINS server. Your NetBIOS scope names have to be consistent across your network for this to work. Another potential pitfall is that NetBIOS scope names are case sensitive, but DNS domain names are case insensitive.
The next two values control timeouts. Cache Timeout Value controls how long the DNS Server will cache information it receives from the WINS server. The default value is 10 minutes. That value may seem small, but it's a good choice: information in the WINS server is transient by nature, so you don't want the DNS Server to hold on to it for a long time. If it needs a name again, the DNS Server can just ask the WINS server for it. Lookup Timeout Value controls how long the DNS Server will wait after querying a WINS server. The default is one second.
You can enable WINS Lookup on in-addr.arpa zones, too. It's called WINS Reverse Lookup. It's implemented differently than plain WINS Lookup. When the name server receives a PTR query it can't answer and WINS Reverse Lookup is enabled for the zone, it sends a NetBIOS Adapter Status request directly to the IP address referenced by the PTR record. In other words, the name server asks the host directly what its name is. The name server can't ask a WINS server because lookups based on IP address aren't supported: you can't give a WINS server an IP address and get the corresponding NetBIOS name back. WINS servers have obviously never heard of Jeopardy! ("The host with IP address 192.249.249.3." "What is terminator ?")
WINS Reverse Lookup is configured similarly to WINS Lookup--select the WINS Reverse Lookup tab of the Zone Properties window of any in-addr.arpa zone. The WINS Reverse Lookup configuration for the 249.249.192.in-addr.arpa zone on the zone's primary, terminator, is shown in Figure 10-7.
Use WINS Reverse Lookup enables the NetBIOS Adapter Status requests for unknown PTR records in this zone. Settings only affect local server has the same effect as its WINS Lookup counterpart. If you look in an in-addr.arpa zone database file, though, you'll see a WINS-R record instead of a WINS record. The DNS Host Domain field takes a DNS domain name that will be appended to the NetBIOS name returned by the host to form a fully qualified domain name. The Advanced button is very similar to the one for WINS Lookup (see Figure 10-8).
There's no reference to NetBIOS scope since it's not applicable here. Cache Timeout Value controls how long the DNS Server will cache the name received from the host. The default value is 10 minutes, just like WINS Lookup. Lookup Timeout Value controls how long the DNS Server will wait on the NetBIOS Adapter Status request. The default is one second.
What's WINS Lookup good for? In most networks, not a lot. The names that get resolved the most are the servers, and they usually have fixed IP addresses and thus static DNS entries. They're resolved directly in DNS, not via the WINS Lookup detour. Most networks don't have much peer-to-peer networking--your average desktop host usually doesn't offer network services, like a web server, name server, and so on. It's the need to reach those kind of network services that requires DNS name resolution to work for every host. (Sure, there's a lot of NetBIOS-based file and print sharing among desktop hosts, but that uses WINS natively.)
If you do need to support WINS Lookup in your network, a big problem with it is that the standard BIND name server doesn't support it. [3] Many people find they need WINS Lookup after they have a DNS infrastructure in place using BIND name servers. One option is to replace all those name servers with the Microsoft DNS Server and enable WINS Lookup. That's not realistic for most people. A better, but not perfect, option is to create a new subdomain for DHCP clients resolvable via WINS Lookup and delegate the subdomain to a set of Microsoft DNS Servers.
For example, let's say the folks running the domain acmebw.com suddenly find themselves with dozens of PCs doing peer-to-peer networking with DHCP-assigned IP addresses. Since they've already got a BIND infrastructure in place, they decide to create the domain pcs.acmebw.com for these PCs. (The domain name could be anything: dhcp.acmebw.com, wins.acmebw.com, projectx.acmebw.com, whatever.) They configure a couple Microsoft DNS Servers for this zone and enable WINS Lookup. Finally, they delegate to the pcs.acmebw.com zone from the acmebw.com zone.
In practice, we find WINS Reverse Lookup is much more useful. It's really nice to have complete reverse mapping information for your network in DNS. Network management applications can report names rather than IP addresses. Web servers can log usage statistics by name and make named-based authorization decisions, like only giving access to hosts in the movie.edu domain. Troubleshooting is easier, as well. Without WINS Reverse Lookup, the name server can't reverse-map dynamically assigned IP addresses. Of course, to use WINS Reverse Lookup, all the name servers for your in-addr.arpa zones need to support WINS Reverse Lookup.
While the default configuration values will work fine for most sites, yours may be one of the rare sites that needs some further tuning. The following tuning requires changes to the Registry. All DNS parameters referenced in this section are values of this Registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
A complete listing of Registry settings for the DNS Server can be found in Appendix G, Microsoft DNS Server Registry Settings.
A zone transfer, we said earlier, comprises many DNS messages sent end to end over a TCP connection. Traditional zone transfers put only a single resource record in each DNS message. That's a waste of space: you need a full header on each DNS message, even though you're only carrying a single record. It's like being the only person in a Chevy Suburban. A DNS message could carry many more records.
The Microsoft DNS Server understands a new zone transfer format that puts as many records as possible into a single DNS message. The resulting "many answers" zone transfer takes less bandwidth, because there's less overhead, and less CPU time, because less time is spent unmarshaling DNS messages.
The DNS Server uses the "many answers" format by default, which is fine if all your slaves can understand it. Older BIND name servers (prior to Version 4.9.4) can't cope with this format and require the traditional one. Fortunately, you can tell the DNS Server to use the traditional method by changing the BindSecondaries Registry value. When set to one, the server sends traditional zone transfers to satisfy older BIND servers. The default value is one, but that doesn't affect zone transfers between two Microsoft DNS Servers. They recognize each other, and the master uses the "many answers" format to the slave.
You should change this value only if you have no BIND slaves, or if all your BIND slaves are running Version 4.9.4 or later.
The Registry value CleanupInterval controls how often the DNS Server performs housekeeping on its memory database of cached records. The default value is 900 seconds (15 minutes), and valid values range from 600 seconds (10 minutes) to 86,400 seconds (24 hours). At every cleanup interval, the name server examines its cache for expired records and removes them. (Expired records are simply ones that have been kept longer than the time to live value set by the name server they came from.) It also verifies that the root name servers are reachable at this interval. If it can't reach any, it reloads the cache file and follows the usual algorithm to obtain a list of root name servers.
We recommend leaving this value at the default. You might want to increase it, though, if your name server is especially busy and running the cleanup interval too often bogs it down. You might also raise it if you want records to persist in the cache longer than their original TTL. Remember, though, that the DNS administrators set the TTL according to their local circumstances, so there might be a very good reason not to keep data longer than the TTL.
One more note about CleanupInterval : if the server receives a response containing an NS record (or its corresponding A record) that's already in the cache, it checks the TTL of the cached record. If the TTL is less than CleanupInterval, the server updates the cached record's TTL with the TTL from the record it just received, essentially refreshing the cached record.
When you are contacting a host that has multiple network interfaces, using a particular interface may give you better performance. If the multihomed host is local and shares a network (or subnet) with your host, one of the multihomed host's addresses is "closer."
Suppose you have an FTP server on two networks, cleverly called network A and network B, and hosts on both networks access the server often. Hosts on network A will experience better performance if they use the server host's interface to network A. Likewise, hosts on network B would benefit from using the server host's interface to network B as the address for their FTP client.
In Chapter4, Setting Up The Microsoft DNS Server, we mentioned that the Microsoft DNS Server returns all the addresses for a multihomed host. There was no guarantee of the order in which a DNS server would return the addresses, so we assigned aliases ( wh249 and wh253 for wormhole) to the individual interfaces. If one interface was preferable, you (or more realistically, a DNS client) could use an appropriate alias to get the correct address. You can use aliases to choose the "closer" interface, but because of address sorting, they are not always necessary.
The post-Service Pack 3 hotfixed version of the Microsoft DNS Server supports address sorting; earlier versions do not. The server sorts addresses, by default, if one condition holds: if the host that sent the query to the name server shares a network with the name server host (for example, both are on network A), then the DNS Server sorts the addresses in the response. How does the DNS Server know when it shares a network with the querier? When it starts up, it finds all the interface addresses of the host it is running on. The DNS Server extracts the network numbers from these addresses to create the default sort list. When a query is received, the DNS Server checks if the sender's address is on a network in the default sort list. If it is, then the query is local, and it sorts the addresses in the response.
In Figure 10-9, assume that a Microsoft DNS Server is on notorious. The name server's default sort list would contain network A and network B. When spellbound sends a query to notorious looking up the addresses of notorious, it will get an answer back with notorious 's network A address first. That's because notorious and spellbound share network A. When charade looks up the addresses of notorious, it will get an answer back with notorious 's network B address first. Both hosts are on network B. In both of these cases, the name server sorts the addresses in the response because the hosts share a network with the name server host. The sorted address list has the "closer" interface first.
Let's change the situation slightly. Suppose the name server is running on gaslight. When spellbound queries gaslight for notorious 's address, spellbound will see the same response as in the last case because spellbound and gaslight share network A, which means that the name server will sort the response. However, charade may see a differently ordered response, since it does not share a network with gaslight. The closer address for notorious may still be first in the response to charade, but only because of luck, not name server address sorting. In this case, you'd have to run an additional name server on network B for charade to benefit from the DNS Server's default address sorting.
As you can see, you benefit by running a name server on each network; not only is your name server available if your router goes down, it also sorts addresses of multihomed hosts. Because the name server sorts addresses, you do not need to specify aliases to get the best response.
There's a small catch with the DNS Server's address sorting: it disables round robin. (Round robin is explained in the section "Load Sharing Between Mirrored Servers ," later in this chapter. ) In the post-SP3 hotfixed server, address sorting is enabled by default and round robin is disabled. If you want round robin and can live without address sorting (unfortunately they're mutually exclusive), you can disable address sorting with the LocalNetPriority value. Set it to zero to disable address sorting and enable round robin. Note, though, that this value doesn't exist in the Registry by default. You'll need to add it before you can change its value to zero.
Certain network connections discourage sending large volumes of traffic off site, either because the network connection is pay-per-packet or because the network connection is a slow link with a high delay, like a remote office's satellite connection to the company's network. In these situations, you'll want to limit the offsite DNS traffic to the bare minimum. The Microsoft DNS Server has a feature to do this called forwarding.
If you designate one or more servers at your site as forwarders, all the offsite queries are sent to the forwarders first. The idea is that the forwarders handle all the offsite queries generated at the site, building up a rich cache of information. For any given query in a remote domain, there is a high probability that the forwarder can answer the query from its cache, avoiding the need for the other servers to send packets off site. Nothing special is done to these servers to make them forwarders; you modify all the other servers at your site to direct their queries through the forwarders.
A primary master or slave name server's mode of operation changes slightly when it is directed to use a forwarder. If the requested information is already in its database of authoritative data and cache data, it answers with this information; this part of the operation hasn't changed. However, if the information is not in its database, the name server will send the query to a forwarder and wait a short period for an answer before resuming normal operation and contacting the remote servers itself. What the name server is doing that's different is sending a recursive query to the forwarder, expecting it to find the answer. At all other times, the name server sends out nonrecursive queries to other name servers and deals with responses that only refer to other name servers.
Forwarding is serverwide, not zone specific: a server is either forwarding or it isn't. It's configured by selecting the Forwarders tab on the Server Properties window. Figure 10-10 shows how a movie.edu name server would be configured to use forwarders, assuming wormhole and terminator are the site forwarders. (Remember, forwarding is configured on every name server except the forwarders themselves-- wormhole and terminator in this case.)
Use Forwarder (s) enables forwarding on this name server. You can specify up to five forwarders. This name server will forward to them in the order they're listed, using a default timeout of five seconds per forwarder--that is, if the first forwarder doesn't respond within five seconds, try the next, wait five more seconds, try the next, and so on. The forwarding timeout can be changed with--surprise!--the Forward Time Out field. This value is stored in a Registry value, ForwardingTimeout, which you can also change. (The list of forwarders is stored in the Forwarders value.) We'll talk about Operate As Slave Server in the next section.
When you use forwarders, try to keep your site configuration simple. You can end up with configurations that are really twisted.
You may want to restrict your name servers even further--stopping them from even trying to contact an offsite server if their forwarder is down or doesn't respond. You can do this by making the server a forwarding server in slave mode or just slave server for short. The terminology gets really confusing, unfortunately: this slave has nothing to do with zone transfers and primary master servers. A name server can be a primary master, slave, or caching-only server and still be forwarding in slave mode. Later versions of the BIND name server eliminate the confusion by calling this a forward only server.
A slave server is a variation on a server that forwards. It still answers queries from its authoritative data and cache data. However, it relies completely on its forwarders; it doesn't try to contact other servers to find out information if the forwarders don't give it an answer. You can turn a forwarding server into a slave server by checking the Operate As Slave Server box in the Forwarders configuration window (see Figure 10-10).
The slave server contacts each forwarder only once, and it waits a short time for the forwarder to respond. Listing the forwarders multiple times directs the forward-only server to retransmit queries to the forwarders, and increases the overall length of time that the forward-only name server will wait for an answer from forwarders. With a slave server, you might want to consider listing the forwarders' IP addresses more than once for redundancy: If the first query to a forwarder is lost, the second might still get through and get answered.
However, you must ask yourself if it ever makes sense to use a slave server. A slave server is completely dependent on the forwarders. You can achieve much the same configuration (and dependence) by not running a slave server at all; instead, configure your hosts' resolvers to point to the forwarders you were using. Thus, you are still relying on the forwarders, but now your applications are querying the forwarders directly instead of having a slave name server query them for the applications. You lose the local caching that the forward only server would have done, and the address sorting, but you reduce the overall complexity of your site configuration by running fewer "restricted" name servers.
By default, resolvers send recursive queries, and name servers do the work required to answer recursive queries. (If you don't remember how recursion works, refer to Chapter 2, How Does DNS Work?) In the process of finding the answer to recursive queries, the name server builds up a cache of nonauthoritative information about other zones.
In some circumstances, it is undesirable for name servers to do the extra work required to answer a recursive query or to build up a cache of data. The root name servers are an example of these circumstances. The root name servers are so busy that they should not be spending the extra effort to recursively find the answer to a request. Instead, they send a response based only on the authoritative data they have. The response may contain the answer, but it is more likely that the response contains a referral to other name servers. And since the root servers do not support recursive queries, they do not build up a cache of nonauthoritative data, which is good because their cache would be huge. [4]
You can induce the Microsoft DNS Server to run as a nonrecursive name server by setting the RecursionNo Registry value to true. By default the name server supports recursion, and this value is false.
If you choose to make one of your servers nonrecursive, do not configure any of your hosts' resolvers to use it. While you can make your name server nonrecursive, there is no corresponding option to make your resolver work with a nonrecursive name server. [5]
You can list a nonrecursive name server as one of the servers authoritative for your zone data (that is, you can tell a parent name server to refer queries about your zone to this server). This works because name servers send nonrecursive queries between themselves.
Do not list a nonrecursive name server as a forwarder. When a name server is using another server as a forwarder, it sends the query to the forwarder as a recursive query instead of a nonrecursive query.
Compared to a modern BIND name server, the Microsoft DNS Server is short on security features, but you do have some options. We'll discuss how to prevent unauthorized zone transfers from your servers and how to "lock down" a name server directly connected to the Internet.
It's important to ensure that only your real slave name servers can transfer zones from your name server. Users on remote hosts that can query your name server's zone data can only look up data (for example, addresses) for hosts whose domain names they already know, one at a time. Users who can start zone transfers from your server can list all of the hosts in your zones. It's the difference between letting random folks call your company's switchboard and ask for John Q. Cubicle's phone number and sending them a copy of your corporate phone directory.
Remember that list of name servers on the Notify window of the Zone Properties window (Figure 10-3)? It has two uses. The first tells the name server which slaves to send NOTIFY messages to. The second is security related. If you check the Only Allow Access From Secondaries Included on Notify List box, the server limits which servers can perform zone transfers: only authorized slaves on the Notify List can initiate a zone transfer.
For a primary master name server accessible from the Internet, you definitely want to limit zone transfers to just your slave name servers. You probably don't need to restrict zone transfers on name servers inside your firewall, unless you're worried about your own employees listing your zone data.
Some of your name servers answer nonrecursive queries from other name servers on the Internet because your name servers appear in NS records delegating your zones to them. We'll call these name servers delegated name servers.
You can take special measures to secure your delegated name servers. But first, you should make sure that these servers don't receive any recursive queries (that is, you don't have any resolvers configured to use these servers, and no name servers use them as forwarders). Some of the precautions we'll take--like disabling recursive queries--preclude your resolvers from using these servers.
Once you know your name server only answers queries from other name servers, you can turn off recursion. This eliminates a major vector of attack: the most common spoofing attacks involve inducing the target name server to query name servers under the hacker's control by sending the target a recursive query for a domain name in a zone served by the hacker's servers. Disabling recursion is described in the section "A Nonrecursive Name Server," earlier in this chapter. You should also restrict zone transfers of your zones to known slave servers, as described in the previous section "Preventing Unauthorized Zone Transfers."
The Microsoft DNS Server has a feature called round robin, named after the equivalent feature in the BIND name server. The server rotates address records for the same domain name between responses. For example, if the domain name foo.bar.baz has three address records for IP addresses 192.1.1.1, 192.1.1.2, and 192.1.1.3, the round robin feature causes the name server to give them out first in the order
192.1.1.1 192.1.1.2 192.1.1.3
192.1.1.2 192.1.1.3 192.1.1.1
192.1.1.3 192.1.1.1 192.1.1.2
before starting over again with the first order, and repeating the rotation ad infinitum.
The functionality is enormously useful if you have a number of equivalent network resources, like mirrored FTP servers, web servers, or terminal servers, and you'd like to spread the load among them. You establish one domain name that refers to the group of resources, configure clients to access that domain name, and the name server inverse-multiplexes the accesses between the IP addresses you list.
It's a good idea to reduce the records' time to live, too. This ensures that, if the addresses are cached on an intermediate name server that doesn't support round robin, they'll time out of the cache quickly. If the intermediate name server looks up the name again, your authoritative name server can round robin the addresses again.
Note that this is really load sharing, not load balancing, since the name server gives out the addresses in a completely deterministic way, without regard to the actual load or capacity of the servers servicing the requests. In our example, the server at address 192.1.1.3 could be a 486DX33 running Linux, and the other two servers HP9000 K420s, and the Linux box would still get a third of the queries.
1. A host's NetBIOS name is simply the name it's known by for NetBT networking purposes. NetBIOS names are limited to one label of up to 15 characters (that is, no multiple label names like DNS domain names). On NT systems the NetBIOS name is set on the Network Control Panel window, Identification tab. A host's NetBIOS name need not be the same as the host name portion of its fully qualified domain name in DNS.
2. But see another book from O'Reilly & Associates, TCP/IP Network Administration by Craig Hunt.
3. MetaInfo has ported BIND to NT and added WINS Lookup and WINS Reverse Lookup. See http://www.metainfo.com.
4. Note that a root name server wouldn't normally receive recursive queries, unless a name server's administrator configured it to use a root server as a forwarder, or a host's administrator configured its resolver to use the root server as a name server, or a user pointed nslookup at the root server.
5. In general. Clearly, programs designed to send nonrecursive queries, or ones that can be configured to send nonrecursive queries, like nslookup, would still work.
© 2001, O'Reilly & Associates, Inc.