When you type a website URL into your browser, a complex network of directory servers works behind the scenes to translate that human-readable name into a machine-readable IP address. This directory database is known as the Domain Name System (DNS). Whether you are setting up a brand-new website, troubleshooting email delivery issues, migrating hosts, or running a security audit, you will frequently need to look up domain records to diagnose and verify configurations.

Learning how to get a record of domain settings is an essential skill for developers, system administrators, and digital marketers alike. In this developer-grade guide, we will explore exactly how to check all domain records using online utilities, Command Prompt, and Unix-based terminals. We will also dive into the exact mechanics of DNS zones, decode complex terminal outputs, and reveal the advanced tips you need to troubleshoot propagation in real-time.

1. Demystifying the DNS Zone File: What Are Domain Records?

Before you run queries, it is crucial to understand what you are actually retrieving. A domain's DNS settings are stored in a text file called a DNS zone file on an authoritative name server. This file acts as a database of mapping entries, known as Resource Records (RRs).

Each record contains specific attributes:

• Name (Host): The subdomain or domain the record applies to (e.g., www or @ for the root domain).
• Type: The class of data the record contains (e.g., A, MX, CNAME).
• Value (Target): The destination IP address, hostname, or text data.
• TTL (Time to Live): The time in seconds that recursive DNS servers should cache the record before fetching a fresh copy.

The Core Record Types You Will Encounter

• A Records: Connect a hostname to an IPv4 address. When you get all a records for domain structures, you are mapping names directly to physical hosting servers.
• AAAA Records: The modern equivalent of A records, mapping hostnames to IPv6 addresses.
• CNAME (Canonical Name): Alias records that point one subdomain to another hostname (e.g., pointing blog.example.com to hosting.provider.com).
• MX (Mail Exchanger): Point incoming emails to the correct mail servers, sorted by a numerical priority value.
• TXT (Text): Hold raw text strings, critical for proving domain ownership and validating secure email authentication protocols.
• NS (Name Server): Authoritative servers that store the official DNS zone file for your domain.
• SOA (Start of Authority): The foundational administrative record that dictates how your DNS zone updates and propagates.

2. Command Line Lookup: Deciphering the 'Dig' Command (macOS & Linux)

For advanced users, the Domain Information Groper (dig) command is the industry-standard tool for checking DNS records. It is native to Unix-based systems (like macOS and Linux) and provides granular control over your queries.

Querying Specific Record Types

To find a record of domain infrastructure, open your terminal and run the dig command followed by the target domain and the record type. For example, to check the IPv4 address mapping:

dig example.com A

To lookup mail servers:

dig example.com MX

To find soa record for domain authority parameters:

dig example.com SOA

Analyzing the Raw Dig Output

Running a raw dig command returns a wealth of diagnostic data. Here is what a typical output looks like when you query a domain's A record:

; <<>> DiG 9.10.6 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48924
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.            IN    A

;; ANSWER SECTION:
example.com.        86400    IN    A    93.184.216.34

;; Query time: 14 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Mon May 25 05:20:00 UTC 2026
;; MSG SIZE  rcvd: 56

Let's break down the essential components of this response:

1. The Header: Shows the status of the query (e.g., status: NOERROR means the lookup succeeded; NXDOMAIN means the domain does not exist).
2. The Question Section: Displays the query you sent—in this case, asking for the A record of example.com class IN (Internet).
3. The Answer Section: The core payload. It shows that example.com has a TTL of 86400 seconds (24 hours), belongs to class IN, type A, and maps to IP address 93.184.216.34.
4. Metadata: Shows the query duration (14 milliseconds), the specific DNS resolver that answered (usually your local router or ISP on port 53), and the precise timestamp.

Advanced Dig Parameters

If you want to clean up the diagnostic clutter and see only the IP addresses or targets, append the +short flag:

dig example.com A +short

To check all records for domain resolving issues from a specific public resolver, specify the server using the @ symbol. This bypasses your local network's cache and queries Google's public DNS directly:

dig example.com A @8.8.8.8

3. Command Line Lookup: Using 'Nslookup' (Windows)

If you are operating in a Windows environment, dig is not natively installed. Instead, Windows provides nslookup via Command Prompt or PowerShell. It is a powerful command-line tool that can run in both single-execution and interactive modes.

Single-Execution Queries

To run a basic query and find a record for domain IP addresses, type:

nslookup example.com

To filter by specific record types, use the -type flag. For example, to check the authoritative name servers:

nslookup -type=ns example.com

To find the Start of Authority (SOA) parameters:

nslookup -type=soa example.com

Operating in Interactive Mode

If you are troubleshooting multiple domains or checking several distinct record types in a row, entering interactive mode is highly efficient. Run:

nslookup

Your command line prompt will change to a > symbol. From here, you can define your query parameters sequentially:

> set type=txt
> example.com
> set type=mx
> example.com
> server 1.1.1.1
> example.com

This interactive sequence sets the search type to TXT, looks up the records for example.com, switches the search type to MX, runs the lookup again, shifts the active DNS server to Cloudflare's public resolver (1.1.1.1), and queries the records once more. Type exit to close the interactive session.

4. How to List All Records for a Domain (And Why It's Hard)

When administrators want to perform security audits, they often ask: How can I get all records for a domain in one single query?

If you look at theoretical DNS documentation, the command to dig domain all records is using the ANY type query:

dig example.com ANY

However, in modern practice, you will find that running an ANY query rarely returns every record.

The Death of the 'ANY' Query

Because ANY queries return massive responses compared to the size of the initial request, bad actors historically leveraged them for DNS Amplification DDoS attacks. In these attacks, hackers send small UDP packets to open DNS resolvers with spoofed victim IP addresses, prompting those resolvers to flood the victim with massive amounts of DNS data. To mitigate this vulnerability, cloud security companies like Cloudflare, Akamai, and major DNS software providers have deprecated, restricted, or entirely disabled responses to public ANY requests. Today, running ANY will often only output a generic warning, a minimal set of basic records, or a configuration error.

Zone Transfers (AXFR): The Administrative Method

To truly list all records for a domain, you would execute an AXFR (Zone Transfer) query. A zone transfer is a valid protocol used to sync zone files between primary and secondary name servers:

dig example.com AXFR @ns1.example.com

The Security Catch: If a DNS server is misconfigured and allows public AXFR requests, anyone on the internet can instantly download every single subdomain and record. This is a severe security vulnerability because it exposes internal-only subdomains to malicious actors. Consequently, virtually all public authoritative name servers block AXFR requests from unauthorized IP addresses.

How Professionals Map an Entire Domain

Because you cannot simply pull a full zone file, cybersecurity professionals and network administrators use alternative techniques to see all records for a domain:

• DNS Enumeration Tools: Software like dnsrecon or subfinder uses a brute-force approach, querying a domain for thousands of common subdomains (e.g., mail, dev, staging, vpn) to see which ones return a valid IP.
• Passive DNS Databases: Services like SecurityTrails, VirusTotal, and Censys collect historical DNS query logs globally. You can query these massive indexes to see all known subdomains and historical records associated with a domain without sending a single direct packet to the target name servers.

5. Security & Verification: TXT and Mail Record Deep Dive

Many developers search for how to find all records for a domain because they are trying to configure secure email sending. To protect against spoofing, phishing, and spam filters, domains rely on three specialized TXT records: SPF, DKIM, and DMARC.

1. SPF (Sender Policy Framework)

An SPF record lists all mail servers authorized to send emails on behalf of your domain. If a server is not on the list, receiving email systems will mark the incoming mail as suspicious.

• How to look up SPF: SPF records are standard TXT records. Run:

dig example.com TXT

Look for a return value that begins with v=spf1 (e.g., v=spf1 include:_spf.google.com ~all).

2. DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing emails, proving the mail was not tampered with during transit. Unlike other records, you cannot look up DKIM records simply by querying the root domain. You must know the DKIM Selector—a unique prefix set up by your email provider.

• How to look up DKIM: If your email provider uses the selector google, your DKIM record is stored at google._domainkey.example.com. Query it using:

dig google._domainkey.example.com TXT

3. DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC tells receiving mail servers how to handle emails that fail SPF or DKIM checks (e.g., do nothing, quarantine them, or reject them outright).

• How to look up DMARC: DMARC records are always located at the subdomain _dmarc.yourdomain.com. Run:

dig _dmarc.example.com TXT

Look for a returned TXT string starting with v=DMARC1.

6. Web-Based Lookups: Testing Propagation and Authority

While command-line interfaces are exceptionally fast, web-based tools have an edge when you need to view global propagation or test how third-party servers see your records.

When to Use Web Tools:

• After Updating Host Settings: When you change your DNS provider, those updates must propagate across millions of resolving servers globally. Using a tool like DNSChecker allows you to verify if your new records are active across servers in London, Tokyo, New York, and Sydney simultaneously.
• Investigating From Restricted Networks: If you are behind a strict corporate firewall that blocks port 53 (DNS traffic) or prevents command-line terminal operations, online lookups are the only way to get a records for domain troubleshooting.
• Generating Reports: Many online tools generate visual PDFs and network health scorecards. These are highly useful when presenting audit findings to non-technical clients or internal stakeholders.

FAQs: Expert Troubleshooting for Domain Records

Why are my newly updated DNS records not showing up yet?

This is caused by DNS caching. When you query a domain, your computer, local router, ISP, and public resolvers all cache the result to speed up future requests. The duration of this cache is defined by the record's TTL (Time to Live) value. If your old record had a TTL of 86,400 seconds, it can take up to 24 hours for resolvers worldwide to request the new record from your authoritative name server.

What is a Start of Authority (SOA) record and why do I need it?

The SOA record contains administrative information about the domain's DNS zone. If you need to find soa record for domain configurations, look for the serial number inside the record data. Every time a DNS record is modified, this serial number increments. If you change your DNS, checking if the serial number has updated is the fastest way to verify that your authoritative server has rebuilt the zone file.

What does NXDOMAIN mean when I run a lookup?

An NXDOMAIN status code means 'Non-Existent Domain'. If you see this, it indicates that the domain name is misspelled, has expired, or the registrar has not pointed the domain to any active authoritative name servers. If the domain was registered very recently, it may still be undergoing the initial registrar-level setup.

How do I clear my computer's DNS cache to see new updates?

If you want to force your computer to fetch fresh records, clear your operating system's DNS cache:

• Windows: Run ipconfig /flushdns in the Command Prompt.
• macOS: Run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder in the Terminal.
• Linux: Depending on your distribution, run sudo systemd-resolve --flush-caches or restart the nscd service.

Can I look up historical DNS records?

Standard tools like dig and nslookup can only show current, active DNS records. To view historical DNS configurations, you must use specialized passive DNS databases such as SecurityTrails, Censys, or DNS History. These systems continuously crawl and index the web, preserving historical snapshots of domain records over years.

Conclusion

Knowing how to look up domain records is a fundamental technical skill that helps you maintain control over your digital infrastructure. Whether you are using dig in a Linux terminal to diagnose email deliverability, troubleshooting slow site loading with nslookup on Windows, or tracking global propagation using visual web interfaces, you now have the tools and structural knowledge to query any DNS zone securely and effectively. By regularly auditing your records, maintaining secure SPF/DKIM/DMARC TXT files, and verifying TTL settings, you can ensure your web applications remain secure, fast, and accessible to visitors worldwide.