🔍 TXT Record Lookup

🎯
Examples: google.com, github.com, 1.1.1.1, 192.168.1.1
📝
🌐
🎮
📋
Enter a domain name or IP address and click"DNS Lookup" to begin...
🔍 Performing DNS lookup...
⚠️ {{ error }}
DNS Query: {{ result.query }} ({{ result.recordType }})
{{ record.name || result.query }}
Type: {{ record.type }}   TTL: {{ record.ttl }}s   Priority: {{ record.priority }}  
{{ record.value }}
{{ record.details }}
No {{ result.recordType }} records found for {{ result.query }}
DNS Server: {{ result.dnsServer }}
Query Time: {{ result.queryTime }}ms
Timestamp: {{ result.timestamp }}
⚡

ℹ️ About DNS Lookup Tool

DNS Lookup Tool queries the Domain Name System for the resource records published under a hostname, domain, or reverse-DNS name. It is an online alternative to nslookup and dig: you choose one record type per query, a server-side resolver answers, and every record comes back with its owner name, type, TTL when the resolver reports one, MX priority, and value.

DNS is built from distributed zones, authoritative name servers, recursive resolvers, caches, and typed resource records. The model is described in RFC 1034, the message and record formats in RFC 1035, and IPv6 address records in RFC 3596. The TXT records you will most often inspect here carry SPF policies per RFC 7208 and DMARC policies per RFC 7489.

Supported inputs

  • Target: one hostname (example.com, www.example.com) or one public IPv4 or IPv6 address (API field host). Names may use ASCII letters, digits, dots, and hyphens, up to 253 characters with labels of at most 63; internationalized names must be given in punycode (xn--) form. Underscore labels such as _dmarc.example.com, whitespace, and shell metacharacters are rejected.
  • Record type: exactly one of A, AAAA, MX, NS, TXT, CNAME, PTR, or SOA (API field recordType, default A). There is no ANY query. The Quick Actions buttons run a single A, MX, NS, or TXT lookup for the current target without changing the selected type, and alias pages such as MX Record Lookup preselect their type.
  • DNS server: Google DNS (8.8.8.8), Cloudflare DNS (1.1.1.1), Quad9 DNS (9.9.9.9), OpenDNS (208.67.222.222), or System Default (API field dnsServer, default 8.8.8.8). See Limitations: the choice is recorded with the result but is not applied to the query at present.
  • Show detailed information: a checkbox that adds a short per-record description and, under each result, the selected DNS server value (its IP address such as 8.8.8.8, or system), the round-trip time measured by the browser, and an ISO 8601 timestamp.
  • Blocked targets: private, loopback, link-local, carrier-grade NAT, documentation, and other reserved IP ranges, plus localhost and names ending in .local, .localdomain, or .internal or starting with test., are refused with HTTP 400 before any query is sent.

Output

Each lookup adds a block headed DNS Query: host (TYPE) to the top of the results panel; the panel keeps the ten most recent lookups so you can compare record types side by side, and Copy exports them as plain text. Every record shows its owner name, type, TTL in seconds when the resolver reported one, the priority for MX records, and the value: an IPv4 or IPv6 address, the target host for MX, NS, CNAME, and PTR, the text string for TXT, or for SOA the primary name server and responsible mailbox, with serial, refresh, retry, expire, and minimum TTL on the details line (visible with Show detailed information) when the web server's resolver answered, or all seven fields on the value line when a worker answered. An empty answer is shown as No TYPE records found.

The API returns the same data as JSON: success, the echoed host, recordType, and dnsServer, a records array of objects with name, type, ttl, priority (MX only), value, and details, the reserved fields authority and additional (currently always null), and an ISO 8601 timestamp. Records are listed in the order the resolver supplied them.

Example

Enter example.com, leave A selected, and click DNS Lookup. The panel shows the header DNS Query: example.com (A) followed by one card per IPv4 address. The equivalent API call and the shape of its answer are below; the address is live data and changes over time, so only the structure is fixed. ttl is null when a network worker served the answer, which is the usual path here, and an integer number of seconds only when the web server's own resolver answered (see Limitations). 

POST /api/tools/network/dns
{"host": "example.com", "recordType": "A", "dnsServer": "8.8.8.8"}

{
  "success": true,
  "host": "example.com",
  "recordType": "A",
  "dnsServer": "8.8.8.8",
  "records": [
    {"name": "example.com", "type": "A", "ttl": null, "value": "<IPv4 address>", "details": "IPv4 address record"}
  ],
  "authority": null,
  "additional": null,
  "timestamp": "2026-09-10T12:00:00+00:00"
}

An MX lookup returns the same objects with an extra priority field. A PTR lookup for 8.8.8.8.in-addr.arpa returns one record whose value is dns.google, the hostname Google publishes for its resolver (worker-served answers keep the trailing dot that dig prints).

Limitations

  • Resolver selection is not applied. The DNS server you pick is echoed in the result, but the query itself uses the resolver configured on the network worker that runs dig +short, or the web server's own resolver when no worker is available. To see what Google, Cloudflare, Quad9, OpenDNS, and other public resolvers each answer, use the DNS Propagation Checker, which queries a fixed set of resolvers directly.
  • TTL depends on the path. Worker-served answers report ttl as null because dig +short prints record data only; the local resolver path reports the TTL it received.
  • One record type per query. There is no ANY lookup, no DNSSEC validation or RRSIG display, and the authority and additional sections are never populated.
  • PTR needs the reversed name on the worker path. The local resolver rewrites an IPv4 address into in-addr.arpa form, but the worker passes the target to dig exactly as typed, and IPv6 addresses are never rewritten. Enter 8.8.8.8.in-addr.arpa or the ip6.arpa name yourself, or use the Reverse DNS Lookup.
  • Empty is not always "does not exist". DNS answers vary by resolver, cache state, TTL, split-horizon configuration, and propagation timing, and the API returns an empty records list rather than an error when the local resolver fails or times out.
  • Underscore names are refused. Records such as _dmarc.example.com or selector._domainkey.example.com fail validation here; the DMARC Record Checker queries _dmarc.<domain> for you.
  • Rate limits: anonymous callers get 20 lookups per minute, 120 per hour, and 400 per day, with a CAPTCHA after 60 in an hour; signed-in users get twice the request limits (40, 240, and 800), while the CAPTCHA threshold stays at 60 per hour for everyone.

Browser or server processing

This tool is server-side only; nothing is resolved in the browser. The page posts host, recordType, and dnsServer (plus an optional worker_id when a peer selector is shown) as JSON to /api/tools/network/dns. The server forwards the query to a registered network worker that runs dig +short, or falls back to PHP dns_get_record() on the web server itself, and that machine's resolver makes the outbound DNS query. The names and addresses you enter are therefore seen by this service, by the worker, and by its upstream resolver, so avoid entering private internal hostnames unless you intend to query them from here.

FAQ

Why do I get "No records found" for a domain that exists?

The resolver returned no records of the selected type at that exact name. Common causes: the data lives under another type (a CNAME at www with the A record only at its target), the record sits on a subdomain such as mail or _dmarc, a PTR query used a bare IP address (see Limitations), or the resolver failed and the API returned an empty list instead of an error. Try the other record types first.

Why does the answer differ from dig or nslookup on my machine?

Your terminal asks your own resolver (or, with dig @server, a server you chose), while this tool asks the resolver configured on the worker or web server that ran the query; the dropdown selection is not applied. Different caches, remaining TTLs, round-robin rotation of multi-address answers, and split-horizon zones all produce different but equally valid answers.

Can I look up a PTR record for an IP address?

Yes. Select PTR and enter the reversed name, for example 8.8.8.8.in-addr.arpa; a bare IPv4 address is rewritten only on the local resolver path and IPv6 addresses never are. The Reverse DNS Lookup tool does this rewriting for both IPv4 and IPv6 addresses.

Why is the TTL missing from some results?

Answers served by a network worker come from dig +short, which prints record data without the TTL, so the field is omitted in the UI and null in the API. Answers from the web server's own resolver include the TTL in seconds.

References

API Usage Example:

POST /api/tools/network/dns
Content-Type: application/json

{
    "host": "example.com",
    "recordType": "MX",
    "dnsServer": "8.8.8.8"
}
Ready