Understanding DNS Traversal

Prev Next

DNS Traversal test is useful for troubleshooting DNS issues since you can see the location from which DNS is resolved, and the performance of the authoritative DNS servers. When analyzing a test where the DNS time increased but Server Response or other metrics on the Components chart has not changed, you'll want to look into see if the DNS is healthy or not.

Simply, run a DNS traversal tool, which is available through Instant Test. This tool will query the entire DNS route in the below order so allowing examination of each server response and respose time.

  1. The Root servers
  2. The GTLD servers
  3. The NS servers

At each level, the test queries each server at that level and logs the response and response time. Once it passes to the GTLD server, the test will run a five-packet ping to each server. If the test cannot connect to one of the NS servers (this may mean that the system received an error, was unable to connect or had packet loss while pinging the server), the test will also run one trace route to the first failing server. Finally, the test queries the last level of NS servers for the HOSTNAME.BIND record to get the host name of the server.

*In order for Catchpoint to retrieve a result for this, the DNS server must be configured to have an entry for HOSTNAME.BIND.

To better understand how the test works, following is a sample of a DNS Traversal test.

Level 1 shows all of the rootservers, authoritative nameservers and additional records followed by test queries of each dns server and logs the response and response time. Below shows when the test was unable to reach the dns server. The test will ping to see if there is an issue at the UDP level. Average Time is slow (~ 5 sec), but there are no Packet Loss.

Address Average Time (ms) Bytes Return Code Error Ping Time Packet Loss
12.34.567.89.10
 [ns1.example.com]
4,529 0 None   38 0% (0/5)
12.34.567.89.13
[ns3.example.org]
4,533 0 None   27 0% (0/5)

Then it runs a trace route to the first server (ns1) that had an issue.

Trace Route : 12.34.567.89.10 [12.34.567.89.10]

Duration (ms) : 9,868

Error : None

Hop Ping 1 (ms) Ping 2 (ms) Ping 3 (ms) Average Time (ms) Packet Loss Address AS Number Status
0 < 1 < 1 < 1 < 1 0% (0/5) 10.109.30.1 [NA] Success
1 1 1 1 1 0% (0/5) 4.30.27.9 [vlan102.car2.denver1.level3.net] Success
2 1 1 1 1 0% (0/5) 4.69.147.72 [ae-1-51.edge3.denver1.level3.net] Success
3 * * * * 100% (5/5) 4.68.70.142 [gblx-level3-1x10g.denver.level3.net] Timed Out
4 27 27 27 27 0% (0/5) 208.178.194.98 [packet-clearing-house.gigabitethernet9-28.ar1.pao2.gblx.net] Success
5 27 27 27 27 0% (0/5) 12.34.567.89.13 [ns3.example.org]

The traceroute and the ping did not show any network issues. If you look at the pings in the top for ns1.example.com and ns3.example.org, you’ll see that it took almost 5 seconds to get anything back.

At the last level of the test, it lists the server that did respond successfully like this one below.  We got answers from ns2 and ns4 so the DNS is healthy. This means that there was an issue at the application level.

Address Average Time (ms) Bytes Return Code Error Ping Time Packet Loss
12.34.567.89.12 [ns2.example.net] ( hostname = phx ) 3,075 0 None 26 0% (0/5)

Query : www.example.com.

Type : A (IPV4 Host Address)

Class : IN (Internet)

Answers

Name TTL Class Type Info
www.example.com. 3,600 IN (Internet) CNAME (Canonical Name for an Alias) sinai.example.com.
sinai.example.com. 10,800 IN (Internet) A (IPV4 Host Address) 69.111.000.32
Address Average Time (ms) Bytes Return Code Error Ping Time Packet Loss
123.4.5.67.78 [ns4.example.info] 32 0 None 32 0% (0/5)

Query : www.example.com.

Type : A (IPV4 Host Address)

Class : IN (Internet)

Answers:

Name TTL Class Type Info
www.example.com. 3,600 IN (Internet) CNAME (Canonical Name for an Alias) sinai.example.com.