named (pronounced name-dee) provides DNS on most Unix machines. It is a server program originally developed for BSD to provide name service to clients, and possibly to other name servers. BIND Version 4 was around for some time and appeared in most Linux distributions. The new release, Version 8, has been introduced in most Linux distributions, and is a big change from previous versions.[1] It has many new features, such as support for DNS dynamic updates, DNS change notifications, much improved performance, and a new configuration file syntax. Please check the documentation contained in the source distribution for details.
This section requires some understanding of the way DNS works. If the following discussion is all Greek to you, you may want to reread the section Section 6.2."
named is usually started at system boot time and runs until the machine goes down again. Implementations of BIND prior to Version 8 take their information from a configuration file called /etc/named.boot and various files that map domain names to addresses. The latter are called zone files. Versions of BIND from Version 8 onwards use /etc/named.conf in place of /etc/named.boot.
To run named at the prompt, enter:
# /usr/sbin/named |
named will come up and read the named.boot file and any zone files specified therein. It writes its process ID to /var/run/named.pid in ASCII, downloads any zone files from primary servers, if necessary, and starts listening on port 53 for DNS queries.
The BIND configuration file prior to Version 8 was very simple in structure. BIND Version 8 has a very different configuration file syntax to deal with many of the new features introduced. The name of the configuration file changed from /etc/named.boot, in older versions of BIND, to /etc/named.conf in BIND Version 8. We'll focus on configuring the older version because it is probably what most distributions are still using, but we'll present an equivalent named.conf to illustrate the differences, and we'll talk about how to convert the old format into the new one.
The named.boot file is generally small and contains little but pointers to master files containing zone information and pointers to other name servers. Comments in the boot file start with the (#) or (;) characters and extend to the next newline. Before we discuss the format of named.boot in more detail, we will take a look at the sample file for vlager given in Example 6-8.
Example 6-8. The named.boot File for vlager
; ; /etc/named.boot file for vlager.vbrew.com ; directory /var/named ; ; domain file ;----------------- cache . named.ca primary vbrew.com named.hosts primary 0.0.127.in-addr.arpa named.local primary 16.172.in-addr.arpa named.rev |
Let's look at each statement individually. The directory keyword tells named that all filenames referred to later in this file, zone files for example, are located in the /var/named directory. This saves a little typing.
The primary keyword shown in this example loads information into named. This information is taken from the master files specified as the last of the parameters. These files represent DNS resource records, which we will look at next.
In this example, we configured named as the primary name server for three domains, as indicated by the three primary statements. The first of these statements instructs named to act as a primary server for vbrew.com, taking the zone data from the file named.hosts.
The cache keyword is very special and should be present on virtually all machines running a name server. It instructs named to enable its cache and to load the root name server hints from the cache file specified (named.ca in our example). We will come back to the name server hints in the following list.
Here's a list of the most important options you can use in named.boot :
This option specifies a directory in which zone files reside. Names of files in other options may be given relative to this directory. Several directories may be specified by repeatedly using directory. The Linux file system standard suggests this should be /var/named.
This option takes a domain name and filename as an argument, declaring the local server authoritative for the named domain. As a primary server, named loads the zone information from the given master file.
There will always be at least one primary entry in every boot file used for reverse mapping of network 127.0.0.0, which is the local loopback network.
This statement takes a domain name, an address list, and a filename as an argument. It declares the local server a secondary master server for the specified domain.
A secondary server holds authoritative data on the domain, too, but it doesn't gather it from files; instead, it tries to download it from the primary server. The IP address of at least one primary server thus must be given to named in the address list. The local server contacts each of them in turn until it successfully transfers the zone database, which is then stored in the backup file given as the third argument. If none of the primary servers responds, the zone data is retrieved from the backup file instead.
named then attempts to refresh the zone data at regular intervals. This process is explained later in connection with the SOA resource record type.
This option takes a domain name and filename as arguments. This file contains the root server hints, which is a list of records pointing to the root name servers. Only NS and A records will be recognized. The domain should be the root domain name, a simple period (.).
This information is absolutely crucial to named; if the cache statement does not occur in the boot file, named will not develop a local cache at all. This situation/lack of development will severely degrade performance and increase network load if the next server queried is not on the local net. Moreover, named will not be able to reach any root name servers, and thus won't resolve any addresses except those it is authoritative for. An exception from this rule involves forwarding servers (see the forwarders option that follows).
This statement takes a whitespace-separated list of addresses as an argument. The IP addresses in this list specify a list of name servers that named may query if it fails to resolve a query from its local cache. They are tried in order until one of them responds to the query. Typically, you would use the name server of your network provider or another well-known server as a forwarder.
This statement makes the name server a slave server. It never performs recursive queries itself, but only forwards them to servers specified in the forwarders statement.
BIND Version 8 introduced a range of new features, and with these came a new configuration file syntax. The named.boot, with its simple single line statements, was replaced by the named.conf file, with a syntax like that of gated and resembling C source syntax.
The new syntax is more complex, but fortunately a tool has been provided that automates conversion from the old syntax to the new syntax. In the BIND 8 source package, a perl program called named-bootconf.pl is provided that will read your existing named.boot file from stdin and convert it into the equivalent named.conf format on stdout. To use it, you must have the perl interpreter installed.
You should use the script somewhat like this:
# cd /etc # named-bootconf.pl <named.boot >named.conf |
Example 6-9. The BIND 8 equivalent named.conf File for vlager
//
// /etc/named.boot file for vlager.vbrew.com
options {
directory "/var/named";
};
zone "." {
type hint;
file "named.ca";
};
zone "vbrew.com" {
type master;
file "named.hosts";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "16.172.in-addr.arpa" {
type master;
file "named.rev";
};
|
If you take a close look, you will see that each of the one-line statements in named.boot has been converted into a C-like statement enclosed within { } characters in the named.conf file.
The comments, which in the named.boot file were indicated by a semicolon (;), are now indicated by two forward slashes ( // ).
The directory statement has been translated into an options paragraph with a directory clause.
The cache and primary statements have been converted into zone paragraphs with type clauses of hint and master, respectively.
The zone files do not need to be modified in any way; their syntax remains unchanged.
The new configuration syntax allows for many new options that we haven't covered here. If you'd like information on the new options, the best source of information is the documentation supplied with the BIND Version 8 source package.
Master files included with named, like named.hosts, always have a domain associated with them, which is called the origin. This is the domain name specified with the cache and primary options. Within a master file, you are allowed to specify domain and host names relative to this domain. A name given in a configuration file is considered absolute if it ends in a single dot, otherwise it is considered relative to the origin. The origin by itself may be referred to using (@).
The data contained in a master file is split up in resource records (RRs). RRs are the smallest units of information available through DNS. Each resource record has a type. A records, for instance, map a hostname to an IP address, and a CNAME record associates an alias for a host with its official hostname. To see an example, look at Example 6-11, which shows the named.hosts master file for the Virtual Brewery.
Resource record representations in master files share a common format:
[domain] [ttl] [class] type rdata |
Fields are separated by spaces or tabs. An entry may be continued across several lines if an opening brace occurs before the first newline and the last field is followed by a closing brace. Anything between a semicolon and a newline is ignored. A description of the format terms follows:
This term is the domain name to which the entry applies. If no domain name is given, the RR is assumed to apply to the domain of the previous RR.
In order to force resolvers to discard information after a certain time, each RR is associated a time to live (ttl ). The ttl field specifies the time in seconds that the information is valid after it has been retrieved from the server. It is a decimal number with at most eight digits.
If no ttl value is given, the field value defaults to that of the minimum field of the preceding SOA record.
This is an address class, like IN for IP addresses or HS for objects in the Hesiod class. For TCP/IP networking, you have to specify IN.
If no class field is given, the class of the preceding RR is assumed.
This describes the type of the RR. The most common types are A, SOA, PTR, and NS. The following sections describe the various types of RRs.
This holds the data associated with the RR. The format of this field depends on the type of RR. In the following discussion, it will be described for each RR separately.
The following is partial list of RRs to be used in DNS master files. There are a couple more of them that we will not explain; they are experimental and of little use, generally.
This RR describes a zone of authority (SOA means “Start of Authority”). It signals that the records following the SOA RR contain authoritative information for the domain. Every master file included by a primary statement must contain an SOA record for this zone. The resource data contains the following fields:
This field is the canonical hostname of the primary name server for this domain. It is usually given as an absolute name.
This field is the email address of the person responsible for maintaining the domain, with the "@" sign replaced by a dot. For instance, if the responsible person at the Virtual Brewery were janet, this field would contain janet.vbrew.com.
This field is the version number of the zone file, expressed as a single decimal number. Whenever data is changed in the zone file, this number should be incremented. A common convention is to use a number that reflects the date of the last update, with a version number appended to it to cover the case of multiple updates occurring on a single day, e.g., 2000012600 being update 00 that occurred on January 26, 2000.
The serial number is used by secondary name servers to recognize zone information changes. To stay up to date, secondary servers request the primary server's SOA record at certain intervals and compare the serial number to that of the cached SOA record. If the number has changed, the secondary servers transfer the whole zone database from the primary server.
This field specifies the interval in seconds that the secondary servers should wait between checking the SOA record of the primary server. Again, this is a decimal number with at most eight digits.
Generally, the network topology doesn't change too often, so this number should specify an interval of roughly a day for larger networks, and even more for smaller ones.
This number determines the intervals at which a secondary server should retry contacting the primary server if a request or a zone refresh fails. It must not be too low, or a temporary failure of the server or a network problem could cause the secondary server to waste network resources. One hour, or perhaps one-half hour, might be a good choice.
This field specifies the time in seconds after which a secondary server should finally discard all zone data if it hasn't been able to contact the primary server. You should normally set this field to at least a week (604,800 seconds), but increasing it to a month or more is also reasonable.
This field is the default ttl value for resource records that do not explicitly contain one. The ttl value specifies the maximum amount of time other name servers may keep the RR in their cache. This time applies only to normal lookups, and has nothing to do with the time after which a secondary server should try to update the zone information.
If the topology of your network does not change frequently, a week or even more is probably a good choice. If single RRs change more frequently, you could still assign them smaller ttls individually. If your network changes frequently, you may want to set minimum to one day (86,400 seconds).
This record associates an IP address with a hostname. The resource data field contains the address in dotted quad notation.
For each hostname, there must be only one A record. The hostname used in this A record is considered the official or canonical hostname. All other hostnames are aliases and must be mapped onto the canonical hostname using a CNAME record. If the canonical name of our host were vlager, we'd have an A record that associated that hostname with its IP address. Since we may also want another name associated with that address, say news, we'd create a CNAME record that associates this alternate name with the canonical name. We'll talk more about CNAME records shortly.
NS records are used to specify a zone's primary server and all its secondary servers. An NS record points to a master name server of the given zone, with the resource data field containing the hostname of the name server.
You will meet NS records in two situations: The first situation is when you delegate authority to a subordinate zone; the second is within the master zone database of the subordinate zone itself. The sets of servers specified in both the parent and delegated zones should match.
The NS record specifies the name of the primary and secondary name servers for a zone. These names must be resolved to an address so they can be used. Sometimes the servers belong to the domain they are serving, which causes a “chicken and egg” problem; we can't resolve the address until the name server is reachable, but we can't reach the name server until we resolve its address. To solve this dilemma, we can configure special A records directly into the name server of the parent zone. The A records allow the name servers of the parent domain to resolve the IP address of the delegated zone name servers. These records are commonly called glue records because they provide the “glue” that binds a delegated zone to its parent.
This record associates an alias with a host's canonical hostname. It provides an alternate name by which users can refer to the host whose canonical name is supplied as a parameter. The canonical hostname is the one the master file provides an A record for; aliases are simply linked to that name by a CNAME record, but don't have any other records of their own.
This type of record is used to associate names in the in-addr.arpa domain with hostnames. It is used for reverse mapping of IP addresses to hostnames. The hostname given must be the canonical hostname.
This RR announces a mail exchanger for a domain. Mail exchangers are discussed in Section 17.4.1.” The syntax of an MX record is:
[domain] [ttl] [class] MX preference host |
host names the mail exchanger for domain. Every mail exchanger has an integer preference associated with it. A mail transport agent that wants to deliver mail to domain tries all hosts who have an MX record for this domain until it succeeds. The one with the lowest preference value is tried first, then the others, in order of increasing preference value.
This record provides information on the system's hardware and software. Its syntax is:
[domain] [ttl] [class] HINFO hardware software |
The hardware field identifies the hardware used by this host. Special conventions are used to specify this. A list of valid “machine names” is given in the Assigned Numbers RFC (RFC-1700). If the field contains any blanks, it must be enclosed in double quotes. The software field names the operating system software used by the system. Again, a valid name from the Assigned Numbers RFC should be chosen.
An HINFO record to describe an Intel-based Linux machine should look something like:
tao 36500 IN HINFO IBM-PC LINUX2.2 |
cevad 36500 IN HINFO ATARI-104ST LINUX2.0 jedd 36500 IN HINFO AMIGA-3000 LINUX2.0 |
There is a special type of named configuration that we'll talk about before we explain how to build a full name server configuration. It is called a caching-only configuration. It doesn't really serve a domain, but acts as a relay for all DNS queries produced on your host. The advantage of this scheme is that it builds up a cache so only the first query for a particular host is actually sent to the name servers on the Internet. Any repeated request will be answered directly from the cache in your local name server. This may not seem useful yet, but it will when you are dialing in to the Internet, as described in Chapter 7 and Chapter 8.
A named.boot file for a caching-only server looks like this:
; named.boot file for caching-only server directory /var/named primary 0.0.127.in-addr.arpa named.local ; localhost network cache . named.ca ; root servers |
In addition to this named.boot file, you must set up the named.ca file with a valid list of root name servers. You could copy and use Example 6-10 for this purpose. No other files are needed for a caching-only server configuration.
Example 6-10, Example 6-11, Example 6-12, and Example 6-13 give sample files for a name server at the brewery, located on vlager. Due to the nature of the network discussed (a single LAN), the example is pretty straightforward.
The named.ca cache file shown in Example 6-10 shows sample hint records for a root name server. A typical cache file usually describes about a dozen name servers. You can obtain the current list of name servers for the root domain using the nslookup tool described in the next section.[2]
Example 6-10. The named.ca File
; ; /var/named/named.ca Cache file for the brewery. ; We're not on the Internet, so we don't need ; any root servers. To activate these ; records, remove the semicolons. ; ;. 3600000 IN NS A.ROOT-SERVERS.NET. ;A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ;. 3600000 NS B.ROOT-SERVERS.NET. ;B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ;. 3600000 NS C.ROOT-SERVERS.NET. ;C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ;. 3600000 NS D.ROOT-SERVERS.NET. ;D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ;. 3600000 NS E.ROOT-SERVERS.NET. ;E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ;. 3600000 NS F.ROOT-SERVERS.NET. ;F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ;. 3600000 NS G.ROOT-SERVERS.NET. ;G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ;. 3600000 NS H.ROOT-SERVERS.NET. ;H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ;. 3600000 NS I.ROOT-SERVERS.NET. ;I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ;. 3600000 NS J.ROOT-SERVERS.NET. ;J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ;. 3600000 NS K.ROOT-SERVERS.NET. ;K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 ;. 3600000 NS L.ROOT-SERVERS.NET. ;L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ;. 3600000 NS M.ROOT-SERVERS.NET. ;M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 ; |
Example 6-11. The named.hosts File
;
; /var/named/named.hosts Local hosts at the brewery
; Origin is vbrew.com
;
@ IN SOA vlager.vbrew.com. janet.vbrew.com. (
2000012601 ; serial
86400 ; refresh: once per day
3600 ; retry: one hour
3600000 ; expire: 42 days
604800 ; minimum: 1 week
)
IN NS vlager.vbrew.com.
;
; local mail is distributed on vlager
IN MX 10 vlager
;
; loopback address
localhost. IN A 127.0.0.1
;
; Virtual Brewery Ethernet
vlager IN A 172.16.1.1
vlager-if1 IN CNAME vlager
; vlager is also news server
news IN CNAME vlager
vstout IN A 172.16.1.2
vale IN A 172.16.1.3
;
; Virtual Winery Ethernet
vlager-if2 IN A 172.16.2.1
vbardolino IN A 172.16.2.2
vchianti IN A 172.16.2.3
vbeaujolais IN A 172.16.2.4
;
; Virtual Spirits (subsidiary) Ethernet
vbourbon IN A 172.16.3.1
vbourbon-if1 IN CNAME vbourbon
|
Example 6-12. The named.local File
;
; /var/named/named.local Reverse mapping of 127.0.0
; Origin is 0.0.127.in-addr.arpa.
;
@ IN SOA vlager.vbrew.com. joe.vbrew.com. (
1 ; serial
360000 ; refresh: 100 hrs
3600 ; retry: one hour
3600000 ; expire: 42 days
360000 ; minimum: 100 hrs
)
IN NS vlager.vbrew.com.
1 IN PTR localhost.
|
Example 6-13. The named.rev File
;
; /var/named/named.rev Reverse mapping of our IP addresses
; Origin is 16.172.in-addr.arpa.
;
@ IN SOA vlager.vbrew.com. joe.vbrew.com. (
16 ; serial
86400 ; refresh: once per day
3600 ; retry: one hour
3600000 ; expire: 42 days
604800 ; minimum: 1 week
)
IN NS vlager.vbrew.com.
; brewery
1.1 IN PTR vlager.vbrew.com.
2.1 IN PTR vstout.vbrew.com.
3.1 IN PTR vale.vbrew.com.
; winery
1.2 IN PTR vlager-if2.vbrew.com.
2.2 IN PTR vbardolino.vbrew.com.
3.2 IN PTR vchianti.vbrew.com.
4.2 IN PTR vbeaujolais.vbrew.com.
|
nslookup is a great tool for checking the operation of your name server setup. It can be used both interactively with prompts and as a single command with immediate output. In the latter case, you simply invoke it as:
$ nslookup hostname |
nslookup queries the name server specified in resolv.conf for hostname. (If this file names more than one server, nslookup chooses one at random.)
The interactive mode, however, is much more exciting. Besides looking up individual hosts, you may query for any type of DNS record and transfer the entire zone information for a domain.
When invoked without an argument, nslookup displays the name server it uses and enters interactive mode. At the > prompt, you may type any domain name you want to query. By default, it asks for class A records, those containing the IP address relating to the domain name.
You can look for record types by issuing:
> set type=type |
in which type is one of the resource record names described earlier, or ANY.
You might have the following nslookup session:
$ nslookup Default Server: tao.linux.org.au Address: 203.41.101.121 > metalab.unc.edu Server: tao.linux.org.au Address: 203.41.101.121 Name: metalab.unc.edu Address: 152.2.254.81 > |
The output first displays the DNS server being queried, and then the result of the query.
If you try to query for a name that has no IP address associated with it, but other records were found in the DNS database, nslookup returns with an error message saying “No type A records found.” However, you can make it query for records other than type A by issuing the set type command. To get the SOA record of unc.edu, you would issue:
> unc.edu
Server: tao.linux.org.au
Address: 203.41.101.121
*** No address (A) records available for unc.edu
> set type=SOA
> unc.edu
Server: tao.linux.org.au
Address: 203.41.101.121
unc.edu
origin = ns.unc.edu
mail addr = host-reg.ns.unc.edu
serial = 1998111011
refresh = 14400 (4H)
retry = 3600 (1H)
expire = 1209600 (2W)
minimum ttl = 86400 (1D)
unc.edu name server = ns2.unc.edu
unc.edu name server = ncnoc.ncren.net
unc.edu name server = ns.unc.edu
ns2.unc.edu internet address = 152.2.253.100
ncnoc.ncren.net internet address = 192.101.21.1
ncnoc.ncren.net internet address = 128.109.193.1
ns.unc.edu internet address = 152.2.21.1
|
In a similar fashion, you can query for MX records:
> set type=MX > unc.edu Server: tao.linux.org.au Address: 203.41.101.121 unc.edu preference = 0, mail exchanger = conga.oit.unc.edu unc.edu preference = 10, mail exchanger = imsety.oit.unc.edu unc.edu name server = ns.unc.edu unc.edu name server = ns2.unc.edu unc.edu name server = ncnoc.ncren.net conga.oit.unc.edu internet address = 152.2.22.21 imsety.oit.unc.edu internet address = 152.2.21.99 ns.unc.edu internet address = 152.2.21.1 ns2.unc.edu internet address = 152.2.253.100 ncnoc.ncren.net internet address = 192.101.21.1 ncnoc.ncren.net internet address = 128.109.193.1 |
Using a type of ANY returns all resource records associated with a given name.
A practical application of nslookup, besides debugging, is to obtain the current list of root name servers. You can obtain this list by querying for all NS records associated with the root domain:
> set type=NS > . Server: tao.linux.org.au Address: 203.41.101.121 Non-authoritative answer: (root) name server = A.ROOT-SERVERS.NET (root) name server = H.ROOT-SERVERS.NET (root) name server = B.ROOT-SERVERS.NET (root) name server = C.ROOT-SERVERS.NET (root) name server = D.ROOT-SERVERS.NET (root) name server = E.ROOT-SERVERS.NET (root) name server = I.ROOT-SERVERS.NET (root) name server = F.ROOT-SERVERS.NET (root) name server = G.ROOT-SERVERS.NET (root) name server = J.ROOT-SERVERS.NET (root) name server = K.ROOT-SERVERS.NET (root) name server = L.ROOT-SERVERS.NET (root) name server = M.ROOT-SERVERS.NET Authoritative answers can be found from: A.ROOT-SERVERS.NET internet address = 198.41.0.4 H.ROOT-SERVERS.NET internet address = 128.63.2.53 B.ROOT-SERVERS.NET internet address = 128.9.0.107 C.ROOT-SERVERS.NET internet address = 192.33.4.12 D.ROOT-SERVERS.NET internet address = 128.8.10.90 E.ROOT-SERVERS.NET internet address = 192.203.230.10 I.ROOT-SERVERS.NET internet address = 192.36.148.17 F.ROOT-SERVERS.NET internet address = 192.5.5.241 G.ROOT-SERVERS.NET internet address = 192.112.36.4 J.ROOT-SERVERS.NET internet address = 198.41.0.10 K.ROOT-SERVERS.NET internet address = 193.0.14.129 L.ROOT-SERVERS.NET internet address = 198.32.64.12 M.ROOT-SERVERS.NET internet address = 202.12.27.33 |
To see the complete set of available commands, use the help command in nslookup.
There are a few tools that can help you with your tasks as a BIND administrator. We will briefly describe two of them here. Please refer to the documentation that comes with these tools for more information on how to use them.
hostcvt helps you with your initial BIND configuration by converting your /etc/hosts file into master files for named. It generates both the forward (A) and reverse mapping (PTR) entries, and takes care of aliases. Of course, it won't do the whole job for you, as you may still want to tune the timeout values in the SOA record, for example, or add MX records. Still, it may help you save a few aspirins. hostcvt is part of the BIND source, but can also be found as a standalone package on a few Linux FTP servers.
After setting up your name server, you may want to test your configuration. Some good tools that make this job much simpler: the first is called dnswalk, which is a Perl-based package. The second is called nslint. They both walk your DNS database looking for common mistakes and verify that the information they find is consistent. Two other useful tools are host and dig, which are general purpose DNS database query tools. You can use these tools to manually inspect and diagnose DNS database entries.
These tools are likely to be available in prepackaged form. dnswalk and nslint are available in source from http://www.visi.com/~barr/dnswalk/ and ftp://ftp.ee.lbl.gov/nslint.tar.Z. The host and dig source codes can be found at ftp://ftp.nikhef.nl/pub/network/ and ftp://ftp.is.co.za/networking/ip/dns/dig/.
| [1] |
BIND 4.9 was developed by Paul Vixie, [email protected], but BIND is now maintained by the Internet Software Consortium, [email protected]. |
| [2] |
Note that you can't query your name server for the root servers if you don't have any root server hints installed. To escape this dilemma, you can either make nslookup use a different name server, or use the sample file in Example 6-10 as a starting point, and then obtain the full list of valid servers. |