Skip to content

dnshostingdomains

How to Check DNS Records for Any Domain (Online and Command Line)

Check DNS records for any domain with an online DNS record lookup, dig, nslookup, PowerShell or DNS over HTTPS. Real output for every command, plus how to query a specific resolver or the authoritative nameserver.
Piotr Kulpinski
26 Mar 2026•8 min read
How to Check DNS Records for Any Domain (Online and Command Line)

You can check DNS records for any domain in a browser or from a terminal. DNS records are public, so a lookup needs no access to the domain's account. This guide shows six ways to run a DNS record lookup, each with real output from wikipedia.org, captured on 12 October 2026.

Quick Answer: To check DNS records online, enter the domain in our DNS lookup tool. It returns the A, AAAA, CNAME, MX, NS, TXT, SOA, CAA and SRV records. On the command line, run dig wikipedia.org MX on macOS or Linux, or nslookup -type=MX wikipedia.org on any system. To see a change the moment you publish it, query the domain's authoritative nameserver: dig @ns0.wikimedia.org wikipedia.org A +norec.

Which DNS records to check

Pick the record type that matches the question. For what each field means, see DNS records explained.

QuestionRecord typeExample command
Which IP does the site point to?A, AAAAdig wikipedia.org A
Is this name an alias?CNAMEdig www.wikipedia.org CNAME
Who handles the domain's email?MXdig wikipedia.org MX
Who runs the domain's DNS?NSdig wikipedia.org NS
Is SPF set up? Is a verification token live?TXTdig wikipedia.org TXT
Is DMARC set up?TXT on _dmarcdig _dmarc.wikipedia.org TXT
Which CAs may issue certificates?CAAdig wikipedia.org CAA
Which zone settings apply?SOAdig wikipedia.org SOA
Which hostname belongs to an IP?PTRdig -x 185.15.59.224

Method 1: check DNS records online

The quickest way is a web-based DNS record lookup. Open our DNS lookup tool, type wikipedia.org and press Look up DNS. The tool:

  • asks Cloudflare's 1.1.1.1 resolver for each record type, with Google's 8.8.8.8 as a fallback
  • shows A, AAAA, CNAME, MX, NS, TXT, SOA, CAA and SRV records for a domain
  • shows the PTR record (reverse DNS) when you enter an IP address instead
  • accepts subdomains and names with underscores, such as _dmarc.wikipedia.org

The tool caches results for up to an hour. If you just changed a record, use the authoritative query in Method 6 to see the new value at once.

To see DNS next to the hosting provider, content delivery network (CDN), SSL certificate and IP location, run a full hosting check instead:

Try it yourself

Check any website's hosting

Enter a domain or IP to see hosting provider, DNS records, and more.

For lookups from code, our API returns the same data. GET https://hostingchecker.online/api/v1/dns?query=wikipedia.org with an Authorization: Bearer YOUR_API_KEY header returns a JSON object with the records under data, one key per record type. The API docs list every field.

The tool does not show HTTPS or SVCB records yet. For those, use dig (Method 2) or DNS over HTTPS (DoH), covered in Method 5.

Method 2: dig (macOS and Linux)

dig comes with macOS and most Linux distributions. On Debian and Ubuntu it is in the dnsutils package. Alpine has it in bind-tools, and Fedora in bind-utils. Give it a name, a record type and, optionally, a resolver after @:

dig @1.1.1.1 wikipedia.org A
; <<>> DiG 9.10.6 <<>> @1.1.1.1 wikipedia.org A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21803
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;wikipedia.org.			IN	A

;; ANSWER SECTION:
wikipedia.org.		146	IN	A	185.15.59.224

;; Query time: 48 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Oct 12 08:49:18 CEST 2026
;; MSG SIZE  rcvd: 58

Three lines matter most:

  • status: NOERROR means the name exists. NXDOMAIN means it does not, and SERVFAIL means the resolver could not get an answer.
  • ANSWER SECTION holds the records. Here: one A record, 185.15.59.224, with 146 seconds left in the resolver's cache.
  • SERVER tells you which resolver answered. Without @, dig uses your system's resolver.

Wikipedia's nameservers answer by location, so from another country you may get a different address.

Short answers

+short prints only the values. Use it in scripts:

dig +short @1.1.1.1 wikipedia.org MX
10 mx-in1001.wikimedia.org.
10 mx-in2001.wikimedia.org.

+noall +answer keeps the full record lines (name, TTL, class, type, value) without the rest:

dig @1.1.1.1 _dmarc.wikipedia.org TXT +noall +answer
_dmarc.wikipedia.org.	600	IN	TXT	"v=DMARC1; p=reject; rua=mailto:dmarc-rua@wikimedia.org;"

Why dig ANY does not list everything

Older guides suggest dig example.com ANY to get every record at once. Many resolvers refuse it or return a short answer. RFC 8482 lets servers return a minimal answer to ANY queries, because full answers were used to amplify DDoS attacks. Cloudflare's resolver refuses outright:

dig @1.1.1.1 wikipedia.org ANY
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 25390
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Ask for each type instead. A short loop does it:

for t in A AAAA MX NS TXT CAA; do echo "$t:"; dig +short @1.1.1.1 wikipedia.org $t; done
A:
185.15.59.224
AAAA:
2a02:ec80:300:ed1a::1
MX:
10 mx-in1001.wikimedia.org.
10 mx-in2001.wikimedia.org.
NS:
ns0.wikimedia.org.
ns1.wikimedia.org.
ns2.wikimedia.org.
TXT:
"yandex-verification: 35c08d23099dc863"
"v=spf1 include:_cidrs.wikimedia.org ~all"
"google-site-verification=AMHkgs-4ViEvIJf5znZle-BSE2EPNFqM1nDJGRyn2qk"
CAA:
0 iodef "mailto:dns-admin@wikimedia.org"
0 issue "letsencrypt.org"
0 issue "pki.goog"

Reverse lookups and HTTPS records

dig -x takes an IP address and finds its PTR record:

dig +short @1.1.1.1 -x 185.15.59.224
text-lb.esams.wikimedia.org.

For HTTPS records you need a recent dig. The version on macOS (9.10.6) does not know the type name. There, ask for TYPE65. The answer comes back as raw hex. BIND's dig 9.20 decodes it:

dig @1.1.1.1 HTTPS cloudflare.com +noall +answer
cloudflare.com.		300	IN	HTTPS	1 . alpn="h3,h2" ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5

Method 3: nslookup (Windows, macOS and Linux)

nslookup is installed on Windows, macOS and most Linux systems. The syntax is nslookup [-type=TYPE] name [server]:

nslookup wikipedia.org 1.1.1.1
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
Name:	wikipedia.org
Address: 185.15.59.224

"Non-authoritative answer" means a resolver answered from its cache or after asking on your behalf. It does not mean the answer is wrong.

nslookup -type=MX wikipedia.org 1.1.1.1
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
wikipedia.org	mail exchanger = 10 mx-in1001.wikimedia.org.
wikipedia.org	mail exchanger = 10 mx-in2001.wikimedia.org.

The same pattern works for -type=NS, -type=TXT, -type=SOA and other types. A name that does not exist gives an NXDOMAIN error:

nslookup no-such-domain-hc60.com 1.1.1.1
Server:		1.1.1.1
Address:	1.1.1.1#53

** server can't find no-such-domain-hc60.com: NXDOMAIN

nslookup does not show TTLs by default. Use dig when you need to know how long an answer stays cached.

Method 4: PowerShell Resolve-DnsName (Windows)

On Windows, PowerShell has Resolve-DnsName. Microsoft describes it as similar to nslookup:

Resolve-DnsName -Name wikipedia.org -Type MX
Resolve-DnsName -Name wikipedia.org -Type TXT -Server 1.1.1.1
Resolve-DnsName -Name wikipedia.org -Type A -DnsOnly

-Server picks the resolver. -DnsOnly skips the LLMNR and NetBIOS fallbacks that Windows otherwise tries. -NoHostsFile ignores the local hosts file.

The cmdlet exists only on Windows. The other commands in this guide ran on macOS, so this section shows no output. Microsoft's reference lists the record types -Type accepts. CAA and HTTPS are not among them, so use dig or DoH for those.

Method 5: DNS over HTTPS with curl

Cloudflare and Google both answer DNS questions over HTTPS and return JSON. This works on any system with curl, including networks that block port 53. Cloudflare needs an accept header (docs):

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=wikipedia.org&type=MX' | jq .
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [{ "name": "wikipedia.org", "type": 15 }],
  "Answer": [
    { "name": "wikipedia.org", "type": 15, "TTL": 300, "data": "10 mx-in1001.wikimedia.org." },
    { "name": "wikipedia.org", "type": 15, "TTL": 300, "data": "10 mx-in2001.wikimedia.org." }
  ]
}

Google's endpoint is https://dns.google/resolve and needs no header (docs):

curl -s 'https://dns.google/resolve?name=wikipedia.org&type=CAA' | jq '.Answer'
[
  { "name": "wikipedia.org.", "type": 257, "TTL": 600, "data": "0 issue \"pki.goog\"" },
  { "name": "wikipedia.org.", "type": 257, "TTL": 600, "data": "0 iodef \"mailto:dns-admin@wikimedia.org\"" },
  { "name": "wikipedia.org.", "type": 257, "TTL": 600, "data": "0 issue \"letsencrypt.org\"" }
]

How to read the JSON:

  • Status is the DNS response code: 0 is NOERROR, 3 is NXDOMAIN, 2 is SERVFAIL.
  • type is a number: 1 is A, 15 is MX, 16 is TXT, 28 is AAAA, 65 is HTTPS, 257 is CAA.
  • AD: true means the resolver validated the answer with DNSSEC. wikipedia.org is not signed, so it is false here.

Both endpoints decode HTTPS records, which makes this the easiest way to read them without a new dig:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=cloudflare.com&type=HTTPS'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,"Question":[{"name":"cloudflare.com","type":65}],"Answer":[{"name":"cloudflare.com","type":65,"TTL":88,"data":"1 . alpn=h3,h2 ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5"}]}

Method 6: query a specific resolver or the authoritative nameserver

Every method above asks a recursive resolver, which may answer from its cache. Different resolvers can hold the same record for different lengths of time. Here are three of them, asked for wikipedia.org at the same moment:

dig @1.1.1.1 wikipedia.org A +noall +answer
dig @8.8.8.8 wikipedia.org A +noall +answer
dig @9.9.9.9 wikipedia.org A +noall +answer
wikipedia.org.		139	IN	A	185.15.59.224
wikipedia.org.		85	IN	A	185.15.59.224
wikipedia.org.		60	IN	A	185.15.59.224

Same address, three different times left in cache. After a change, one resolver can return the new value while another still returns the old one until its TTL runs out.

To skip caches entirely, ask the authoritative nameserver, the server that holds the zone. Find it with an NS lookup, then query it with +norec (no recursion):

dig +short @1.1.1.1 wikipedia.org NS
dig @ns0.wikimedia.org wikipedia.org A +norec
ns0.wikimedia.org.
ns1.wikimedia.org.
ns2.wikimedia.org.

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63454
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
wikipedia.org.		180	IN	A	185.15.59.224

The aa flag means "authoritative answer". The TTL is the full value the owner set, 180 seconds, not a countdown. If the authoritative server shows your new record, the change is published. The rest is resolvers catching up.

With nslookup, put the nameserver last, and the "Non-authoritative answer" line disappears:

nslookup wikipedia.org ns0.wikimedia.org
Server:		ns0.wikimedia.org
Address:	208.80.154.238#53

Name:	wikipedia.org
Address: 185.15.59.224

What the results tell you

  • NXDOMAIN: the name does not exist. For a whole domain, check that it is registered and not expired with our WHOIS lookup tool.
  • NOERROR with an empty answer: the name exists, but has no record of that type. example.com returns this for CAA, because it publishes none.
  • SERVFAIL: the resolver could not get a valid answer. Common causes are broken DNSSEC and nameservers that do not respond.
  • Different answers from different resolvers: caching after a change, or a provider that answers by location, as Wikipedia does.
  • An A record pointing at a CDN: the address belongs to the CDN, not the host. Our IP lookup tool shows who owns an address, and how to find out who hosts a website explains how to look past the CDN.

For email problems, start with the MX, SPF and DMARC records. How to check MX records goes through them one by one.

Frequently Asked Questions

How do I check DNS records for a domain?

Enter the domain in an online DNS lookup tool such as our DNS lookup tool, or run dig domain.com TYPE (macOS, Linux) or nslookup -type=TYPE domain.com (any system). Replace TYPE with the record you need, such as A, MX or TXT.

Can I see all DNS records for a domain at once?

Not with one query. Many resolvers refuse or shorten ANY queries (RFC 8482), and most nameservers block zone transfers, the only standard way to list every name in a zone. Query each record type you need. An online tool does this for you and shows the common types together.

Can I look up DNS records for a domain I don't own?

Yes. DNS records are public, so anyone can query them. Subdomains are the exception in practice: you can only look up a subdomain if you know its name.

How do I check if my DNS changes are live?

Query the authoritative nameserver with dig @ns1.yourprovider.com yourdomain.com A +norec. If it returns the new value, the change is published. Public resolvers show it once the old TTL has run out.

What is the difference between dig and nslookup?

Both send DNS queries. dig shows the full response, including flags, TTLs and the responding server, which makes it better for debugging. nslookup ships with Windows and prints a shorter answer without TTLs by default.

Why do two DNS lookup tools show different results?

They may ask different resolvers, which cache records for different lengths of time. Some domains also answer by location. Querying the authoritative nameserver gives the answer the owner published.

Wrapping up

DNS records are public, so any of these six methods works for any domain. For a quick look, use our DNS lookup tool. For debugging, use dig against a named resolver, then against the authoritative nameserver. If the two disagree, the cause is usually caching, or a provider that answers by location.

Piotr Kulpinski

Written by

Founder of HostingChecker.online and a web developer with over a decade of experience in DNS, hosting infrastructure, and domain management. Piotr builds tools that help developers and site owners understand their web stack. Other products: Highseat, OpenAlternative, EuroAlternative, Revinel and Dirstarter.

Free lookup tool

Check any website's hosting

Enter a domain or IP to uncover hosting details, DNS records, and server location.