A complete guide to how the NSLookup Tool works, what each DNS record type means, and how to use DNS-over-HTTPS lookups for real diagnostic work.
Launch the NSLookup Tool →The NSLookup Tool queries DNS resource records for any domain name, letting you choose exactly which record type you want to see: A (IPv4 address), AAAA (IPv6 address), CNAME (canonical name/alias), MX (mail exchange), TXT (text, often used for domain verification and SPF/DKIM email authentication), NS (name server), SOA (start of authority), SRV (service locator), CAA (certification authority authorization), PTR (reverse lookup), or ANY, which requests all common record types at once.
Beyond simply picking a record type, the tool also lets you choose which public DNS resolver answers the query (Cloudflare's 1.1.1.1 or Google Public DNS's 8.8.8.8), and offers two advanced toggles: requesting DNSSEC validation data, and setting the cd (checking disabled) flag, which tells the resolver not to perform its own DNSSEC validation and return the raw answer even if it would otherwise fail validation. These options exist specifically for the kind of detailed diagnostic work DNS administrators actually need, rather than only offering the simplest possible lookup.
This tool mirrors the function of the traditional nslookup or dig command-line utilities found on virtually every operating system, but makes the same functionality available instantly in a browser tab, with results formatted clearly rather than as raw terminal output.
Ordinarily, DNS queries are sent using a dedicated, decades-old protocol running over plain UDP packets on port 53 — a mechanism that long predates the web and that browsers have no built-in way to speak directly, for the same reason they can't send raw ICMP packets for a true ping: it requires low-level network socket access that web pages are deliberately not given.
The modern solution is DNS-over-HTTPS (DoH), standardized in RFC 8484, which wraps a DNS query inside a normal HTTPS request — the same kind of request any web page can make. This is exactly why DoH exists as a protocol in the first place: it was designed partly to let DNS queries travel over infrastructure (standard HTTPS) that is already universally supported, encrypted by default, and compatible with web technology, including JavaScript running in a browser.
This tool sends its queries to Cloudflare's or Google's DoH JSON API endpoints, both of which were confirmed through direct testing to support the CORS headers needed for a browser page to read the response (the same CORS mechanism explained in depth in the DNS Propagation Tool's documentation). Both providers return a clean, well-structured JSON object containing the answer section, which this tool parses and displays as a readable table rather than raw JSON.
Because the query is a real DoH request to a real, operational public resolver, the answer you get is the same authoritative answer any device on the internet using that resolver would get — this tool is not simulating DNS lookups or using any kind of cached or approximate data source.
It's worth noting that this is the exact same underlying mechanism modern browsers like Firefox and Chrome increasingly use by default for their own built-in DNS resolution, when a user enables "Secure DNS" or "DNS over HTTPS" in their browser settings. This tool simply exposes that same capability directly and transparently, letting you choose the resolver and record type explicitly rather than relying on whatever the browser's built-in secure DNS feature is configured to do in the background.
Each DNS record type serves a distinct purpose, and choosing the right one matters for getting a useful answer:
Different public resolvers occasionally cache DNS answers for slightly different durations, or see slightly different intermediate states during a change's propagation window, so offering a choice between two major, independent providers lets you cross-check a result rather than relying on a single source. This complements the DNS Propagation Tool, which checks many resolvers at once for propagation status specifically, while this tool is oriented toward detailed, single-query diagnostics with full control over record type and advanced flags.
Both Cloudflare and Google were chosen for the same reason they appear in the DNS Propagation Tool's working set: both were directly confirmed through live testing to support the CORS headers required for a browser-based tool to read their responses, and both offer a straightforward JSON API rather than requiring a custom binary wire-format parser the way Quad9 does.
example.com.Looking up the TXT record for a domain during email configuration might reveal an SPF record like v=spf1 include:_spf.google.com ~all, confirming that Google Workspace is authorized to send email on that domain's behalf — a common step when diagnosing why legitimate email is landing in a recipient's spam folder.
DNS lookups are one of the first things any experienced system administrator checks when something isn't working right, because so many problems that look like application bugs or server crashes are actually DNS misconfigurations. A few recurring scenarios illustrate why having full control over record type and resolver matters:
In each of these cases, having a fast, no-signup, browser-based way to check the exact record in question — without needing to install command-line tools or remember their syntax — turns a multi-step diagnostic process into a single lookup.
Each query is sent directly from your browser to the DoH resolver you select (Cloudflare or Google), exactly as if your operating system's own DNS-over-HTTPS feature had made the request. NexTechTools does not operate any server in this flow and does not log, store, or see the domains you query or the answers returned.
As with any DNS query sent to any resolver, the resolver itself does see the domain name being asked about. Cloudflare and Google each publish their own privacy policies describing how they handle DNS query data, independent of this tool.
Not every domain configures every record type. A domain without a mail server, for example, will correctly return no MX records, and a domain that doesn't use DNSSEC will return no DNSSEC-related data. An empty result is often the correct, accurate answer rather than an error.
TTL (time-to-live) is the number of seconds a DNS resolver is instructed to cache that specific answer before asking the authoritative server again. A lower TTL means changes propagate faster but increases query load; a higher TTL means slower propagation after changes but reduces load on the authoritative name servers.
If a domain's DNSSEC configuration has a problem, a resolver performing full validation may refuse to return an answer at all, reporting a SERVFAIL error instead. Setting the checking-disabled flag asks the resolver to skip that validation step and return the raw answer anyway, which is useful specifically for diagnosing what might be misconfigured.
No. The DNS Propagation Tool checks a single record type (A records) across many resolvers at once to assess global propagation status. This tool is built for deep, single-query diagnostics: any record type, DNSSEC data, and advanced query flags, against one resolver at a time.