201
FTP is another protocol that uses NVT ASCII and can be checked, to a very limited extent, with telnet. Here is a quick check to see if the server is up and can be reached:
lnx1 telnet bsd2 ftp Trying 172.16.2.236...
Connected to bsd2.lander.edu. Escape character is ].
220 bsd2.lander.edu FTP server Version 6.00LS ready. user jsloan
331 Password required for jsloan. pass xyzzy
230 User jsloan logged in. stat
211- bsd2.lander.edu FTP server status: Version 6.00LS
Connected to 172.16.3.234 Logged in as jsloan
TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: Stream No data connection
211 End of status quit
221 Goodbye. Connection closed by foreign host.
Once you know the server is up, youll want to switch over to a real FTP client. Because FTP opens a reverse connection when transferring information, you are limited with what you can do with telnet.
Fortunately, this is enough to verify that the server is up, communication works, and you can successfully log on to the server.
Unlike FTP, TFTP is UDP based. Consequently, TCP-based tools like telnet are not appropriate. Youll want to use a TFTP client to test for connectivity. Fortunately, TFTP is a simple protocol and
usually works well.
10.1.4 Name Services
Since name resolution is based primarily on UDP, you wont be able to debug it with telnet. Name resolution can be a real pain since problems are most likely to show up when you are using other
programs or services. Name service applications are applications that youll want to be sure are working on your system. For clients, it is one of the easiest protocols to test. For servers, however,
ferreting out that last error can be a real chore. Fortunately, there are a number of readily available tools, particularly for DNS.
If you suspect name resolution is not working on a client, try using ping, alternating between hostnames and IP addresses. If you are consistently able to reach remote hosts with IP addresses but
not with names, then you are having a problem with name resolution. If you have a problem with name resolution on the client side, start by reviewing the configuration files. It is probably easiest to
start with etchosts and then look at DNS. Leave NIS until last.
10.1.4.1 nslookup and dig
There are several tools, such as nslookup, dig, dnsquery, and host, that are used to query DNS servers. These are most commonly used to retrieve basic domain information such as what name goes with
what IP address, aliases, or how a domain is organized. With this information, you can map out a network, for example, at least to the extent the DNS entries reflect the structure of the network. When
troubleshooting on the client side, it can be used to ensure the client can reach the appropriate DNS
TE AM
FL Y
Team-Fly
®
202
server. The real value for troubleshooting, however, is being able to examine the information returned by servers. This allows you to check this information for consistency, correctness, and completeness.
For most purposes, there is not much difference among these programs. Your choice will largely be a matter of personal preference. However, you should be aware that some other programs may be built
on top of dig, so be sure to keep it around even if you prefer one of the other tools.
Of these, nslookup, written by Andrew Cherenson, is the most ubiquitous and the most likely to be installed by default. It is even available under Windows. It can be used either in command-line mode
or interactively. In command-line mode, you use the name or IP address of interest as an argument:
sol1 nslookup 205.153.60.20 Server: lab.lander.edu
Address: 205.153.60.5 Name: ntp.lander.edu
Address: 205.153.60.20 bsd2 nslookup www.lander.edu
Server: lab.lander.edu Address: 205.153.60.5
Name: web.lander.edu Address: 205.153.60.15
Aliases: www.lander.edu
As you can see, it returns both the name and IP address of the host in question, the identity of the server supplying the information, and, in the second example, that the queried name is an alias. You
can specify the server you want to use as well as other options on the command line. You should be aware, however, that it is not unusual for reverse lookups to fail, usually because the DNS database is
incomplete.
Earlier versions of nslookup required a special format for finding the names associated with IP addresses. For example, to look up the name associated with 205.153.60.20, you would have used the
command
nslookup 20.60.153.205.in-addr.arpa
. Fortunately, unless you are using a very old version of nslookup, you wont need to bother with this.
While command-line mode is adequate for an occasional quick query, if you want more information, youll probably want to use nslookup in interactive mode. If you know the right combination of
options, you could use command-line options. But if you are not sure, it is easier to experiment step- by-step in interactive mode.
Interactive mode is started by typing
nslookup
without any arguments:
sol1 nslookup Default Server: lab.lander.edu
Address: 205.153.60.5
As you can see, nslookup responds with the name of the default server and a prompt. A ? will return a list of available options. You can change the server you want to query with the server command. You
can get a listing of all machines in a domain with the ls command. For example, ls netlab.lander.edu would list all the machines in the netlab.lander.edu domain. Use the ls command with caution—it can
return a lot of information. You can use the -t option to specify a query type, i.e., a particular type of
203
record. For example, ls -t mx lander.edu will return the mail entries from lander.edu. Query types can include cname to list canonical names for aliases, hinfo for host information, ns for name servers for
named zones, soa for zone authority record, and so on. For more information, start with the manpage for nslookup.
One useful trick is to retrieve the soa record for local and authoritative servers. Here is part of one such record retrieved in interactive mode:
ls -t soa lander.edu [lab.lander.edu]
ORIGIN lander.edu. 1D IN SOA lab root
960000090 ; serial
The entry labeled
serial
is a counter that should be incremented each time the DNS records are updated. If the serial number on your local server, when compared to the authoritative server, is off by
more than 1 or 2, the local server is not updating its records in a timely manner. One possible cause is an old version of bind.
Many administrators prefer dig to nslookup. While not quite as ubiquitous as nslookup, it is included as a tool with bind and is also available as a separate tool. dig is a command-line tool that is quite easy
to use. It seems to have a few more options and, since it is command line oriented, it is more suited for shell scripts. On the other hand, using nslookup interactively may be better if you are groping around
and not really sure what you are looking for.
dig, short for Domain Internet Groper, was written by Steve Hotz. Here is an example of using dig to do a simple query:
bsd2 dig lander.edu www.lander.edu ; DiG 8.3 lander.edu www.lander.edu
; 1 server found ;; res options: init recurs defnam dnsrch
;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1 ;; QUERY SECTION:
;; www.lander.edu, type = A, class = IN ;; ANSWER SECTION:
www.lander.edu. 1D IN CNAME web.lander.edu. web.lander.edu. 1D IN A 205.153.60.15
;; AUTHORITY SECTION: lander.edu. 1D IN NS lander.edu.
;; ADDITIONAL SECTION: lander.edu. 1D IN A 205.153.60.5
;; Total query time: 9 msec ;; FROM: bsd2.lander.edu to SERVER: lander.edu 205.153.60.5
;; WHEN: Tue Nov 7 10:26:42 2000 ;; MSG SIZE sent: 32 rcvd: 106
The first argument, in this case
lander.edu
, is optional. It gives the name of the name server to be queried. The second argument is the name of the host you are looking up.
204
As you can see, a simple dig provides a lot more information, by default at least, than does nslookup. It begins with information about the name server and resolver flags used. The flags are documented
in the manpage for bind s resolver. Next come the header fields and flags followed by the query being answered. These are followed by the answer, authority records, and additional records. The
format is the domain name, TTL field, type code for the record, and the data field. Finally, summary information about the exchange is included.
You can also use dig to get other types of information. For example, the -x option is used to do a reverse name lookup:
bsd2 dig -x 205.153.63.30 ; DiG 8.3 -x
;; res options: init recurs defnam dnsrch ;; got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUERY SECTION: ;; 30.63.153.205.in-addr.arpa, type = ANY, class = IN
;; ANSWER SECTION: 30.63.153.205.in-addr.arpa. 1D IN PTR sloan.lander.edu.
;; AUTHORITY SECTION: 63.153.205.in-addr.arpa. 1D IN NS lander.edu.
;; ADDITIONAL SECTION: lander.edu. 1D IN A 205.153.60.5
;; Total query time: 10 msec ;; FROM: bsd2.lander.edu to SERVER: default -- 205.153.60.5
;; WHEN: Mon Nov 6 10:54:17 2000 ;; MSG SIZE sent: 44 rcvd: 127
The mx option no hyphen will return mail records, the soa option will return zone authority records, and so on. See the manpage for details.
nslookup and dig are not unique. For example, host and dnsquery are other alternatives you may want to look at. host is said to be designed as a successor for nslookup and dig. But it does everything
online and can generate a lot of traffic as a result. While very useful tools, all of them rely on your ability to go back and analyze the information returned. There are other tools that help to fill this gap.
10.1.4.2 doc, dnswalk, and lamers
