What is dig +trace?

Dig +trace fully tracks the delegation chain for the domain in question. It can go from root name servers, to the top-level domain (TLD) servers and authoritative name servers. Dig +trace helps teams troubleshoot DNS resolution problems.

The most immediately apparent problems would be an outright failure to connect with a certain domain or subdomain, as evidenced by a failure notice screen. Another type of DNS resolution problem is latency, which can extend query times beyond normal human patience.

Average DNS lookup time is measured in milliseconds (MSEC) and tends to fall somewhere in the range between 20 MSEC and 120 MSEC. Optimization efforts seek to further reduce those query times.

In a normal dig command, your DNS server, acting as your internet service provider’s (ISP) resolver, issues a recursive request and checks its local caches for a recent, unexpired DNS record. But that’s what happens in an ideal situation, when everything goes to form. 

Administrators turn to dig +trace when they need to go “under the hood.” Usually, you need to bypass the usual query process because something has gone wrong. There’s some part of the routing chain that’s not performing correctly. Therefore, administrators need to be able to dissect and study parts of that chain and its various linkages to find out what’s not operating correctly.

When teams use dig +trace, they effectively disregard what’s been previously cached, so they can run a fresh and iterative query without being routed down old and obsolete pathways.

Dig +trace is useful for troubleshooting because it allows you to see where DNS resolution is breaking. The issue might be in the root, TLD or authoritative level. It can also check whether your domain’s name server records are correct and verify DNS propagation after changes.

The dig +trace process really comes down to four steps.

If the user previously entered that domain name and the computer cached its IP address command prompt (CMD) instantly retrieves the needed IP address. The system accesses and downloads the requested content and the query process ends then and there. 

However, if the domain name is new and unknown to that device, the rest of these steps are run.

The dig command seeks out the root name servers for the name server (NS) records associated with the top-level domain (TLD) of the target domain being surveyed.

The dig command investigates TLD name servers to discover the authoritative name servers for a particular domain.

The dig command then queries the authoritative name servers to access the requested DNS records. For example, the “A record” is a resource record that associates a human-friendly domain name with an IPv4 or IPv6 address. Meanwhile, Start of Authority (SOA) records hold the necessary administrative data for a DNS zone.

The DNS response that’s given includes the “answer section,” which is resource records that can successfully respond to the original query (also known as the “question section”).

In addition, the response might also have an authority section that lists authoritative name servers and possibly an “additional section” that contains extra information. Administrators can select exactly what types of records they desire, whether that means mail servers (MX records) or name servers (NS records). 

At each investigative step along that path, administrators receive output messages to let them know the status of each phase and if the progression is continuing as intended.

For example, the administrator sees a “NOERROR” message to let them know that there were no incidents in this stage of the test. (Note: That message doesn’t indicate overall operational success or failure and should not be misinterpreted. While useful, it’s limited in what information it conveys.)

It’s interesting to observe that the DNS infrastructure helps support the DNS hierarchy and uses an ingenious system of referrals to assist the lookup process. In this way, if one server cannot usher the query through to completion, it essentially guides the query to another server that aids its progress and extend its journey. 

The domain name system used by the internet is composed of different root name servers operating at various levels. Of prime importance are the 13 logical root name servers working at the top level, which are named for the first 13 letters of the alphabet.

Each of these 13 logical root name servers refers not to single computers or operating systems but instead represents a designated authority that governs one thirteenth of all internet DNS query traffic. So, when we refer to “Server A,” we’re referring to the Server A designation, which can cover an unlimited number of individual DNS servers.

It’s also worth noting that the 13 root name servers are delegated to a varied bunch of entities—assorted for-profit companies mixed with university and military organizations. And while it’s true that originally the location of most physical servers was heavily concentrated in the United States, that equation has been rebalanced over time. Now, physical servers are located across the globe.

Here are the groups that maintain responsibility for running the 13 different root-servers.net designations:

• Server A (a.root-servers.net): Operator: VeriSign, Inc., which offers internet infrastructure and domain name registry services around the world.

• Server B (b.root-servers.net): Operator: The University of Southern California (ISI). USC’s Information Sciences Institute studies advanced computer and communication tech.

• Server C (c.root-servers.net): Operator: Cogent Communications, an international ISP that manages a substantial fiber optic network and offers colocation services.

• Server D (d.root-servers.net): Operator: The University of Maryland and managed by its Advanced Cyberinfrastructure and Internet Global Services (ACIGS) group.

• Server E (e.root-servers.net): Operator: NASA, more specifically the US space agency’s Network and Telecommunication Services (NaTS) service line. 

• Server F (f.root-servers.net): Operator: Internet Systems Consortium, Inc., a non-profit corporation that supports the internet by offering various software and protocols. 

• Server G (g.root-servers.net): Operator: US Department of Defense Network Information Center (NIC), which is also responsible for managing the DoD’s IPv6 address plan.

• Server H (h.root-servers.net): Operator: US Army Research Laboratory (ARL), which was formerly known as the Ballistics Research Laboratory (BRL). 

• Server I (i.root-servers.net): Operator: Netnod, a Swedish non-profit internet infrastructure organization predominantly known for interconnection services within Nordic regions. 

• Server J (j.root-servers.net): Operator: VeriSign, Inc. (See Server A). 

• Server K (k.root-servers.net): Operator: Reseaux IP Europeens Network Coordination Centre (RIPE NCC), a not-for-profit Regional internet Registry (RIR) devoted to Europe, Middle East and Asia. 

• Server L (l.root-servers.net): Operator: Internet Corporation for Assigned Names and Numbers (ICANN), a non-profit organization that began through a US government contract but now exists as a separate, global-centric entity.

• Server M (m.root-servers.net): Operator: The WIDE Project, which stands for Widely Integrated Distributed Environment, this Internet project began through a collaboration of three Japanese universities. 

Query traffic is distributed evenly across the 13 servers, with no server handling more than another. Regional factors can influence which servers users access most, but overall the traffic is similar, mostly involving requests for ISP addresses.

The reason it takes 13 entities to manage DNS query traffic is that trillions of DNS queries are generated for each year. Some estimations have the total to climb over 100 trillion, but those numbers are educated guesses. It’s such a large number that it really cannot be calculated.

There are a handful of tangentially related issues that should also be addressed:

• One way to get even more utility from DNS is by using Extension Mechanisms for DNS (EDNS). EDNS is a collection of enhancements for DNS protocols. When administrators encounter larger DNS message payloads, EDNS adapts to carrying these oversized data packages. In addition to accommodating bigger messages, EDNS also offers options like EDNS Client Subnet (ECS), which boosts performance levels for applications often impacted by latency issues. 

• The OPT pseudosection is a unique type of DNS record started by EDNS. It carries useful transaction information but not standard DNS data. The OPT pseudosection is included in the “additional data” section of DNS messages. It provides details like EDNS versions, flags and the maximum packet size for User Datagram Protocol (UDP), a commonly used query format. 

• Linux operating systems and certain Unix-like systems rely upon the etc/resolv.conf configuration file to notify the system to activate its resolver routines to find IP addresses for corresponding hostnames. This file’s contents include the IP addresses of DNS servers, lists of domains to search, local domain names and options that let you determine resolver actions. These actions can include global options, which are settings that administrators can apply unilaterally. 

• Unix-like systems that don’t really use DNS often contain a manual page (or “man page”). This page serves as the documentation that outlines defined data about a particular command file, system call or configuration file. Man pages provide a general sense of context about system files and tools, focusing on information such as command or program name, synopsis, description and options.