NOTE: The content on this page is partially copied from R. Scott
Perry's website,
DNS Oversimplified:
http://www.rscott.org/dns/
http://www.rscott.org/dns/soa.html
Ping is like a network echolocation mechanism.
Ping stands for "Packet INternet Groper." An Internet utility used to determine whether a particular IP address is reachable online by sending out a packet and waiting for a response. Ping is used to test and debug a network as well as see if a user or server is online.
Ping sends ICMP ECHO_REQUEST packets to any network addressable host (i.e. a server, a gateway router, etc.). The piece of equipment must be IP (Internet Protocol) addressable in order for ping to work
Ping is useful for determining whether a host is up and running on the network. Ping returns information regarding the hosts response to the ICMP ECHO_REQUEST packets.
Ping on Windows machine sends four datagram packets to be delivered:
ping hostname
-or-
ping nn.nn.nn.nn
where nn.nn.nn.nn is an IP address. For example:
ping localhost
-or-
ping 127.0.0.1
unknown host hostname
Most likely cause: the host you pinged isn't a valid fully qualified domain name.
The host you pinged is a valid fully qualified domain name, but ping could not establish a network connection to it. Could be that the host is down. Another possibility is that your local machine has fallen off the network. Maybe the local gateway router is down.
Another error:
4 packets transmitted, 3 packets received, 25% packet loss
Don't be too alarmed by packet losses. Any loss under 50-60% might be normal for a heavily loaded network circuit.
If you can ping an IP host on a different network, it suggests that both hosts have TCP/IP correctly initialized and configured, and that routing between the networks is also configured correctly.
In cases where you cannot ping a remote host, don't jump to the conclusion that the remote host is unavailable or misconfigured, though it might be, the problem may also be a configuration issue with the source host, or potentially some routing-related (or physical connectivity) issue between the two. As a general rule, use the following steps to determine the source of connectivity issues between your PC and a remote system:
Assuming that your IP address, subnet mask, and default gateway are correct, attempt to ping a host on a different subnet. If this fails, one possibility is that routing is not configured correctly.
If pinging a remote host fails, attempt to ping your default gateway. If this fails, it may indicate that TCP/IP is not configured correctly on your local router interface, on your host PC, or that the router interface has not been enabled with the no shutdown command.
If pinging your default gateway fails, try pinging your host's configured IP address. If this fails, it can may mean that you have configured your host PC's IP address incorrectly, or that TCP/IP is not properly installed or initialized on the host system.
If pinging the host's IP address fails, try pinging the loopback address 127.0.0.1. If this fails, it generally indicates that TCP/IP is not properly installed or initialized on your host system.
Tracert is another command line utility built into Windows and most other computer systems. The basic tracert command syntax is:
tracert hostname
-or-
tracert nn.nn.nn.nn
where nn.nn.nn.nn is an IP address. For example:
tracert microsoft.com
-or-
tracert 207.46.197.32
Tracert sends an ICMP echo packet, but it takes advantage of the fact that most Internet routers will send back an ICMP TTL expired in transit message if the TTL field is ever decremented to zero by a router. Using this knowledge, we can discover the path taken by IP Packets.
First, tracert sends out an ICMP echo packet to the named host with a TTL of 1, second - with a TTL of 2, then - with a TTL of 3, and so on. Tracert eventually gets TTL expired in transit message back from the routers until the desination host computer finally is reached.
When the host computer is reached, it responds with the standard ICMP echo reply packet. The tracert then prints Trace complete and stops.
The tracert action can be roughly emulated using the -i option of ping. This option is asking ping to set the specific TTL value of outgoing ping packets. For example, the sequence of commands
ping -i 1 microsoft.com
ping -i 2 microsoft.com
ping -i 3 microsoft.com
ping -i 4 microsoft.com
...
results in "TTL expired in transit" messages, but sooner or later will get the destination host, microsoft.com, responding.
Tracert Round Trip Times: Each millisecond (ms) time in the table is the round-trip time that it took (to send the ICMP packet and to get the ICMP reply packet). The faster (smaller) the times the better. ms times of 0 mean that the reply was faster than the computers timer of 10 milliseconds, so the time is actually somewhere between 0 and 10 milliseconds.
Tracert Packet Loss: Packet loss is indication of the deteriorated throughput. Having no packet loss is critical to having a connection to the Internet that responds well. Thus, a slower connection with zero packet loss can easily outperform a faster connection with some packet loss. Also, packet loss on the last hop, the desination, is what is most important. Sometimes routers in-between will not send ICMP "TTL expired in transit" messages, causing what looks to be high packet loss at a particular hop, but all it means is that the particular router is not configured to respond with the ICMP echo.
The nslookup command runs queries against DNS servers for answers related to network host/domain name resolution. Nslookup is an interactive program to find records of the following types:
------------------------------------------------------------
Type Description
------ -----------------------------------------------------
a IP address
cname Canonical name for an alias
hinfo Host CPU and operating system type
mx Mail exchanger records
ns Name server record
soa Core information about the host (Start of Authority)
any Union of all records
------------------------------------------------------------
When nslookup starts, it prints the name and IP address of your local DNS server. Commands
> set type=a > google.com.
generate output:
Non-authoritative answer:
Name: google.com
Addresses: 74.125.45.100
209.85.171.100
74.125.67.100
Note that Non-authoritative answer clause means that you are looking up google.com not the first time, which means that the the name server uses its cache to generate the answer, resulting in the "Non-authoritative" answer.
Using trailing dot at the end of the fully qualified domain name is equivalent to set nosearch (see below.) This is important when debugging DNS servers. The dot is preferred.
Commands
> set type=mx
> google.com
generate output:
Non-authoritative answer: google.com MX preference = 10, mail exchanger = smtp3.google.com google.com MX preference = 10, mail exchanger = smtp4.google.com google.com MX preference = 10, mail exchanger = smtp1.google.com google.com MX preference = 10, mail exchanger = smtp2.google.com smtp4.google.com internet address = 72.14.221.25 smtp1.google.com internet address = 209.85.237.25 smtp2.google.com internet address = 64.233.165.25 smtp3.google.com internet address = 209.85.137.25
The first four lines show that the domain google.com has four MX records. Mail addressed to that domain is sent to the machine with the lowest preference (cost). If that machine is down or not accepting mail, the message is sent to the machine with the next higher cost, and so on. The last four lines show the IP addresses (A records) for those machines.
Note that machines that have MX records do not necessarily have A records. For example, commands
> set type=a
> www.ddddddddd.com.
where ddddddddd is such domain name, could generate output including the line
*** No address information available for www.ddddddddd.com.
Commands
> set type=soa
> www.yahoo.com.
may yield output such as
Non-authoritative answer:
www.yahoo.com canonical name = www.wa1.b.yahoo.com
www.wa1.b.yahoo.com canonical name = www-real.wa1.b.yahoo.com
wa1.b.yahoo.com
primary name server = yf1.yahoo.com
responsible mail addr = hostmaster.yahoo-inc.com
serial = 1240708009
refresh = 30 (30 secs)
retry = 30 (30 secs)
expire = 86400 (1 day)
default TTL = 1800 (30 mins)
The SOA record provides core information about the host. It defines which server is the primary nameserver, your contact information (E-mail), how your secondary nameservers get updated, and the default (minimum) Time-To-Live values for the server records. In particular,
MNAME ("Primary NS") - This is a fully qualified domain name. This entry is the domain name of the name server, the original source of the data, the "primary nameserver." This primary nameserver, is the one and only server that gets updated; then, all secondary servers are updated automatically, based on the SOA record.
RNAME ("Responsible Person") - This is a DOMAIN NAME that indicates the E-mail address of the person responsible. this zone. It MUST be in the format username.domain.tld, for example bob.example.com, which corresponds to the E-mail address bob@example.com
If this record has an "@" sign in it, it is wrong. Some programs, such as Sam Spade, may put the "@" sign in there when displaying it. Check the actual SOA record to be sure. If this record doesn't have a domain name in it (i.e., just a "hostmaster"), it is wrong. It is recommended [RFC1912 2.2] to use the format hostmaster.example.com, of course making sure that hostmaster@example.com is a valid E-mail address.
If the E-mail address has a dot "." in it, there must be a backslash "\" before it (for example, john\.smith.example.com for john.smith@example.com. Again there should be no "@" sign in this entry, otherwise there is an error.
SERIAL - This is a serial number (32-bit unsigned integer) that is incremented on the primary name server whenever a change is made. The recommended [RFC1912 2.2] value for this is a 10-digit number in the form YYYYMMDDnn (year, month, date, revision). For example, if change occured on June 14, 2008, the entry could indicate 2008061401. If change happens again on that day, the entry is incremented to 2008061402, and so forth. This is very useful to determine the last day the files were changed (especially handy when looking at cached entries in other DNS servers).
REFRESH - The number of seconds (32-bit integer) between the time that a secondary name server gets a copy of the zone (or sees that it hasn't changed), and the next time it checks to see if it needs a new copy. This is set to the amount of time the webmaster thinks it is okay for secondary servers to have out-of-date information when the primary server is updated. An hour or two might be considered an acceptable value. If set too short (like 1 minute), this might cause more traffic.
RETRY - The number of seconds (32-bit integer) that the primary name server(s) wait if attempt to refresh has failed, before making another attempt to refresh. If primary nameserver is reliable, this value almost never is needed.
EXPIRE - The number of seconds (32-bit integer) that lets the secondary name server(s) know how long they can hold the information before it is no longer considered authoritative. A good value might be 2 to 4 weeks [RFC1912 2.2]. It is typically long enough to keep the data during a major outage. This value is typically greater than the minimum and retry intervals (or else the data would immediately expire if the secondary server could not reach the primary server.)
MINIMUM ("Minimum TTL") - The number of seconds that the records in the zone are valid for (time-to-live, or TTL), unless the records have a higher TTL value. This is VERY important setting. The setting could be a week, one day, or less, like 30 seconds, if the server changes its DNS often.
Debugging is turned off by default. If it is turned on, the name server shows timeouts and displays the response packets. See [no]d2 for a discussion of debug level 2.
By default, nslookup adds the default domain name to names without a dot in them. Before search lists existed, the resolver code would only add the default domain to names without any dots in them; this option reflects that behavior. nslookup can implement the pre-search list behavior (with search off and defname on), or it can implement the search list behavior (with search on).
The search option "overshadows" the default domain name (defname) option. That is, defname only applies if search is turned off. By default, nslookup appends the domains in the search list (srchlist) to names that don't end in a dot.
nslookup requests recursive service by default. This turns on the recursion-desired bit in query packets. The resolver sends recursive queries in the same way. Name servers, however, send out nonrecursive queries to other name servers.
Debugging at level 2 is turned off by default. If it is turned on, you see the query packets sent out in addition to the regular debugging output. Turning on d2 also turns on debug. Turning off d2 turns off d2 only; debug is left on. Turning off debug turns off both debug and d2.
By default, nslookup makes queries using UDP packets instead of over a virtual circuit (TCP). Most resolver queries are made with UDP, so the default nslookup behavior matches the resolver. As the resolver can be instructed to use TCP, so can nslookup.
By default, nslookup doesn't ignore truncated packets. If a packet is received that has the "truncated" bit set - indicating that the name server couldn't fit all the important information in the UDP response packet - nslookup doesn't ignore it; it retries the query using a TCP connection instead of UDP. Again, this matches the resolver behavior. The reason for retrying the query using a TCP connection is that TCP responses can be twice as large as UDP responses. TCP responses could be many times the size of a UDP response (a TCP connection can carry much more data than a single UDP packet), but the buffers resolver uses for a TCP query are only twice as large as the UDP buffers.
The DNS service is on port 53. You can start a name server on another port - for debugging purposes, for example - and nslookup can be directed to use that port.
By default, nslookup looks up A (address) resource record types. In addition, if you type in an IP address (and the nslookup query type is address or pointer), then nslookup will invert the address, append in-addr.arpa, and look up PTR (pointer) data instead.
The only class that matters is Internet. Well, there is the Hesiod (HS) class too, if you are an MITer or run Ultrix.
If the name server doesn't respond within 5 seconds, nslookup resends the query and doubles the timeout (to 10, 20, and then 40 seconds). The resolver uses the same timeouts when querying a single name server.
Send the query four times before giving up. After each retry, the timeout value is doubled. Again, this matches the resolver behavior.
There is a convenience command called root, which switches your default server to the server named here. Executing the root command from a modern nslookup's prompt is equivalent to executing server a.root-servers.net. Older versions use nic.ddn.mil (old) or even sri-nic.arpa (ancient) as the default root name server. You can change the default "root" server with set root=server.
This is the default domain appended if the defname option is on.
If search is on, these are the domains appended to names that do not end in a dot. The domains are listed in the order that they are tried, separated by a slash.