is it dns? / wiki ← back to the live monitor

The dig-along

Every record on this page is real and live on isitdns.net. Open a terminal and run the dig command. The answer should match. If it doesn't, that's a story: see when-its-dns. One expected difference: the records are published with a 300-second TTL, and caches count TTLs down, so seeing 287 or 42 instead of 300 just means your resolver answered from cache.

The example records are all under example.isitdns.net so they're easy to spot in your DNS provider's dashboard. Each section also shows an nslookup equivalent for readers without dig. Where nslookup cannot demonstrate the behavior, a note explains why and points to the right tool.

No dig? macOS ships it (brew install bind for the newer version). Linux: apt install dnsutils. Windows: WSL or Resolve-DnsName in PowerShell. See nslookup-and-dig for a side-by-side comparison.

1. A: the IPv4 record#

The A record maps a name to an IPv4 address. It is the most queried record type in DNS.

dig +short A example.isitdns.net
192.0.2.1
nslookup -type=A example.isitdns.net

192.0.2.0/24 is TEST-NET-1, reserved by RFC 5737 for documentation (it also reserves TEST-NET-2, 198.51.100.0/24, and TEST-NET-3, 203.0.113.0/24). It will never route. That's deliberate: every example IP on this page comes from documentation-reserved space.

2. AAAA: the IPv6 record#

The AAAA record maps a name to an IPv6 address.

dig +short AAAA example.isitdns.net
2001:db8::1
nslookup -type=AAAA example.isitdns.net

2001:db8::/32 is the IPv6 documentation prefix (RFC 3849). Same idea, IPv6 flavor.

Why two records for one name? A and AAAA are independent. Modern clients query both and use Happy Eyeballs (RFC 8305) to race the connection. When you "lose IPv6," it's usually because AAAA exists but the route doesn't.

3. CNAME: aliases#

A CNAME record is an alias: it tells the resolver to look up a different name and return whatever that name resolves to.

dig cname.example.isitdns.net

Look at the ANSWER section:

cname.example.isitdns.net.  300 IN CNAME  example.isitdns.net.
example.isitdns.net.        300 IN A      192.0.2.1
nslookup cname.example.isitdns.net

A CNAME tells the resolver "follow this name." The resolver then asks for the A/AAAA at the target and returns both records in the answer. cname.example.isitdns.net is not an IP: it's a pointer.

CNAME chain#

dig chain.example.isitdns.net
chain.example.isitdns.net.  300 IN CNAME  cname.example.isitdns.net.
cname.example.isitdns.net.  300 IN CNAME  example.isitdns.net.
example.isitdns.net.        300 IN A      192.0.2.1
nslookup chain.example.isitdns.net

Two hops. The resolver chases the chain transparently. There is no RFC-specified limit on chain length; implementations historically return SERVFAIL somewhere between 8 and 16 hops to avoid runaway loops.

The "no CNAME at apex" rule. A zone apex (isitdns.net itself, no subdomain) cannot host a CNAME because it must hold SOA and NS records, and CNAMEs cannot coexist with other records at the same name. Cloudflare and some others fake apex-CNAME with "CNAME flattening": they resolve the chain server-side and return A records instead.

4. Wildcard: * matches anything#

dig +short A literally-anything.wildcard.example.isitdns.net
dig +short A another-random-name.wildcard.example.isitdns.net
192.0.2.1
192.0.2.1
nslookup -type=A literally-anything.wildcard.example.isitdns.net
nslookup -type=A another-random-name.wildcard.example.isitdns.net

Both return 192.0.2.1. A wildcard also matches deeper names, as long as nothing closer exists:

dig +short A one.two.wildcard.example.isitdns.net
192.0.2.1

nslookup works here too:

nslookup -type=A one.two.wildcard.example.isitdns.net

The *.wildcard.example.isitdns.net record matches any name below wildcard.example.isitdns.net that has no closer match, at any depth (RFC 4592). So foo.wildcard.example, one.two.wildcard.example, and a.b.c.wildcard.example all resolve. The common belief that "a wildcard only matches one label" is a myth. A wildcard stops covering part of a branch only when you add an explicit node in between: create two.wildcard.example and *.wildcard.example no longer synthesizes one.two.wildcard.example, because two.wildcard.example becomes the closest match.

Wildcards are a footgun. They mask typos: dig amail.example.com resolving means your mail config "works" by accident. Many production zones explicitly avoid them.

5. TXT: arbitrary text#

TXT records carry freeform text. SPF, DKIM, DMARC, and domain-ownership verification tokens all live here.

dig +short TXT txt.example.isitdns.net
"It was DNS. It is always DNS."
nslookup -type=TXT txt.example.isitdns.net

And a terse one:

dig +short TXT answer.example.isitdns.net
"Yes."
nslookup -type=TXT answer.example.isitdns.net

TXT longer than 255 bytes#

dig +short TXT long.example.isitdns.net
"This TXT string is longer than 255 bytes, so DNS splits it into multiple character strings that get re-joined on the client side. It is the same wire-format trick used heavily by SPF, DKIM, and DMARC, whose records routinely exceed the" " 255-byte single-string cap and must be chunked the same way."
nslookup -type=TXT long.example.isitdns.net

The DNS wire format limits a single TXT string to 255 bytes. To send longer text, the record contains multiple strings concatenated. dig shows them as quoted segments; the application (an SPF or DKIM parser, for example) joins them back into one string.

nslookup cannot show multi-string TXT records clearly on all platforms. Use dig.

6. MX: mail exchange#

MX records tell sending mail servers which host accepts email for a domain. A domain with no MX at all can still receive mail: senders fall back to its A/AAAA record, the "implicit MX" rule of RFC 5321 section 5.1. To declare that a domain accepts no mail, publish a Null MX, a single 0 . record (RFC 7505).

dig +short MX mx.example.isitdns.net
10 mx.example.com.
nslookup -type=MX mx.example.isitdns.net

The 10 is the priority. Lower wins. Multiple MX records with the same priority round-robin; when priorities differ, the higher-numbered (backup) MX is only tried if the lower-numbered (primary) one fails.

7. SRV: service location#

SRV records let a protocol discover the host and port for a service, without hardcoding either in the client.

dig +short SRV _xmpp-server._tcp.example.isitdns.net
10 5 5269 example.com.
nslookup -type=SRV _xmpp-server._tcp.example.isitdns.net

Format: priority weight port target. SRV lets a protocol discover the host and port for a service. XMPP, SIP, LDAP, Kerberos, Minecraft: all use SRV.

The leading underscores (_xmpp-server._tcp) are conventions, not magic. They scope SRV records to a service+protocol pair under the parent zone.

8. CAA: who's allowed to issue certs#

CAA records restrict which certificate authorities may issue TLS certificates for a domain. See caa-policy for the full policy model.

dig +short CAA caa.example.isitdns.net
0 issue "letsencrypt.org"
nslookup -type=CAA caa.example.isitdns.net

Some older versions of nslookup display CAA as rdata_257 = 0 issue "letsencrypt.org" instead of the parsed form. The data is the same; the label differs.

CAA tells CAs "only this CA is allowed to issue certificates for me." A compliant CA must check CAA before signing. Without CAA, any public CA in your client's trust store can mint a cert for your domain.

Now query the zone apex to see this zone's own real CAA policy:

dig +short CAA isitdns.net
0 issue "comodoca.com"
0 issue "digicert.com; cansignhttpexchanges=yes"
0 issue "letsencrypt.org"
0 issue "pki.goog; cansignhttpexchanges=yes"
0 issue "sectigo.com"
0 issue "ssl.com"
0 issuewild "comodoca.com"
0 issuewild "digicert.com; cansignhttpexchanges=yes"
0 issuewild "letsencrypt.org"
0 issuewild "pki.goog; cansignhttpexchanges=yes"
0 issuewild "sectigo.com"
0 issuewild "ssl.com"
nslookup -type=CAA isitdns.net

Cloudflare auto-injects entries for every CA backing its edge certificates. The list can grow when Cloudflare adds a new CA partner; the entries shown above reflect the live zone at the time of writing.

9. NS: delegation#

NS records identify the authoritative nameservers for a zone. See delegations for how delegation works end to end.

dig +short NS isitdns.net
coleman.ns.cloudflare.com.
hera.ns.cloudflare.com.
nslookup -type=NS isitdns.net

These are the authoritative nameservers for the entire zone. Anyone resolving *.isitdns.net ends up asking one of these (or a cache layer that already did).

The split-horizon trick. On a network running split-horizon DNS, the same NS query can return different answers depending on which view your source IP matches.

10. SOA: zone authority#

The SOA record defines the zone itself: primary nameserver, admin email, and the timing parameters that govern zone transfers and negative caching.

dig +short SOA isitdns.net
coleman.ns.cloudflare.com. dns.cloudflare.com. 2406968847 10000 2400 604800 1800
nslookup -type=SOA isitdns.net

The fields are: primary NS, zone admin email (. substituted for @), serial, refresh, retry, expire, minimum. The minimum field (1800 here) is the negative cache TTL (RFC 2308): how long resolvers cache NXDOMAIN answers for this zone (strictly, RFC 2308 takes the lower of this field and the SOA record's own TTL; Cloudflare sets both to 1800). The serial you see will differ from the one above; it increments every time the zone changes.

nslookup shows the SOA fields labeled by name (origin, mail addr, serial, etc.), which is often more readable than the flat dig +short output.

11. The DNSSEC ad flag#

DNSSEC adds cryptographic signatures to DNS records. isitdns.net is fully signed: DNSKEY and RRSIG records are present (ECDSA P-256), and a DS record (keytag 2371) is published at the .net parent, so the chain of trust is complete from the root down.

Request the signatures with +dnssec:

dig +dnssec isitdns.net A @1.1.1.1 | grep -E "flags:|RRSIG"
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
isitdns.net.  300 IN RRSIG A 13 2 300 20260718135341 20260716115341 34505 isitdns.net. ...

The RRSIG confirms the zone is signed. (The two timestamps are the signature's expiration and inception; Cloudflare re-signs the zone continuously, so the dates you see will differ.) The ad (Authenticated Data) flag is the second indicator: it means a validating resolver confirmed the entire chain from root to this record. Whether ad appears in the flags: line depends on your local network path. Transparent DNS proxies, some VPNs, and consumer routers strip it.

To see ad reliably, use DNS-over-HTTPS directly to Cloudflare's resolver, bypassing any local interception:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=isitdns.net&type=A'
{
  "Status": 0,
  "AD": true,
  ...
  "Answer": [
    {"name": "isitdns.net", "type": 1, "TTL": 300, "data": "..."},
    {"name": "isitdns.net", "type": 1, "TTL": 300, "data": "..."}
  ]
}

"AD": true is the DoH equivalent of the ad flag. This path is not interceptable by your local resolver.

nslookup cannot request or display DNSSEC signatures or the AD bit. On Windows, Resolve-DnsName cloudflare.com -Type A -DnssecOk requests signatures but does not validate the chain end to end.

To prove that a validating resolver actually rejects bad signatures, query a deliberately broken zone:

dig dnssec-failed.org @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: ...

A validating resolver returns SERVFAIL for dnssec-failed.org because the zone publishes DNSKEYs that do not match the parent DS record. No SEP key satisfies the DS hash, so the chain of trust breaks (EDE 9: DNSKEY Missing). NOERROR means validation is not reaching you. DNSSEC is intentionally hard-fail: there is no graceful degradation.

See dnssec-troubleshooting for the failure patterns and how to diagnose them.

12. PTR: reverse DNS#

PTR records map an IP address back to a name. They live in the .in-addr.arpa hierarchy for IPv4 and .ip6.arpa for IPv6. See reverse-dns for the full model.

You cannot reverse-lookup 192.0.2.1 (documentation space; nobody owns the reverse zone). But for a real public host:

dig +short -x 1.1.1.2
security.cloudflare-dns.com.
nslookup 1.1.1.2

-x is shorthand: it flips the octets and queries the .in-addr.arpa reverse zone, so 1.1.1.2 goes out on the wire as 2.1.1.1.in-addr.arpa. (1.1.1.1 hides this, since it reads the same reversed.)

The explicit form, which shows exactly what happens on the wire:

dig +short PTR 2.1.1.1.in-addr.arpa
security.cloudflare-dns.com.

nslookup reverses the IP automatically when you pass it a bare IPv4 address, just like dig -x.

Where to go next#