When DNS fails, everything fails. That is why having the right tools to gain visibility into how your domain resolves is critical. One such tool is dig – short for Domain Information Groper – a diagnostic command-line utility tool that allows users to query DNS servers directly and inspect the responses in detail.
Dig is a command-line tool used to query DNS name servers and retrieve information about domain records. It is used for troubleshooting DNS issues, verifying configurations and inspecting how queries resolve from a particular source.
Dig is widely used by network administrations, developers, SREs, DevOps and IT professionals to troubleshoot and diagnose DNS-related issues.
-
Inspect DNS record types and values (A, AAAA, MX, TXT, etc)
Unlike browser-based lookups, dig provides granular control over how queries are made, and which servers are queried - making it ideal for testing DNS behavior under real-world conditions.
Dig is usually pre-installed on most linux and MacOS systems. If not, it can be installed with:
Homebrew: brew install bind
Debian/Ubuntu: sudo apt install dnsutils
Red Hat/CentOS/Fedora: sudo dnf install bind-utils
Windows does not include dig by default, options include:
Installing BIND Tools: from ISC.org
Use Windows Subsystem for Linux (WSL): Install dnsutils
PowerShell Alternative: Use Resolve-DnsName
These tools are useful for quick lookups or when working from a restricted environment.
Using dig to Test NS1 Connect Filter Chain
IBM NS1 Connect DNS platform features Filter Chains – powerful functionality that dynamically processes DNS answers based on metadata such as server health, geography, or real user performance. This allows for intelligent routing decisions that adapt in real time.
To test how your Filter Chain is functioning:
dig examplezone.com @dns1.p04.nsone.net
This command queries NS1 Connect authoritative DNS servers directly, returning the DNS response after Filter Chain policies are applied.
Simulating Geolocation-Based Routing
If your Filter Chain includes geo-targeting or performance-based filters, you can simulate queries from different locations using the EDNS Client Subnet option:
dig examplezone.com @dns1.p04.nsone.net +subnet=1.2.3.4
This simulates a DNS query as if it originated from the IP address1.2.3.4, allowing you to test how the Filter Chain responds to different geographic or network conditions. This method is particularly useful for validating that users in different regions are being routed to the correct endpoints based on your configuration.
Understanding a dig Output
Running a dig query returns a detailed response and understanding the structure of a response is essential. A typical output includes:
Header: contains metadata such as the query ID, status and flags.
Question section: the query made, including domain name and record type.
Answer section: the actual answer.
Authority section: lists authoritative name services – useful for delegation checks.
Additional section: often includes IP addresses of name services from the authority section.
Query time and Server information: helps you diagnose response time and identify resolver.
You can also use +short for a clean, stripped-down output.
Lets take a look at a real dig command: dig www.ibm.com
status: NOERROR: The query was successful.
flags: qr rd ra: Indicates it’s a query response (qr), recursion was desired (rd), and recursion was available (ra).
Shows the query made: the A record for www.ibm.com.
www.ibm.com is a CNAME (Canonical Name) pointing to www.ibm.com.edgekey.net.
The actual A record (IPv4 address) is 23.204.218.128.
Query Time and Server Info:
Query time: 16 msec: Time taken to get the response.
SERVER: 10.255.255.254: The DNS resolver used for the query.
Dig is a no-nonsense tool for DNS testing and troubleshooting. Whether you are checking basic records or validating advanced routing with NS1 Connect Filter Chains, it offers the visibility and control needed to ensure your DNS is working as intended.
You can refer to the NS1 Help Centre for more information and step by step guides:
#Technical
#TechnicalBlog