NetSight

DNS Lookup

Resolve DNS records for any hostname: A, AAAA, MX, TXT, NS, SOA, CNAME and CAA in one view, with DNSSEC status. Enter an IP address for its reverse PTR name.

About DNS lookup

Resolve any hostname from an authoritative DNS over HTTPS resolver. NetSight queries records in parallel and shows A, AAAA, CNAME, MX, TXT, NS, SOA and CAA together with the DNSSEC status, so you see the full picture in one view instead of running multiple dig commands. Enter an IP address instead of a name to get its reverse PTR record.

Record types

  • A / AAAA: the IPv4 and IPv6 addresses the name resolves to.
  • CNAME: a canonical-name redirect: this name is an alias for another.
  • MX: mail exchangers, ordered by preference.
  • TXT: free-form records often used for SPF, DKIM, DMARC, domain-verification tokens.
  • NS / SOA: the authoritative nameservers and the zone start-of-authority record.
  • CAA: Certificate Authority Authorization: which CAs are allowed to issue certificates for the domain.
  • SRV: service records used by XMPP, SIP, Minecraft and others.

When it's useful

  • Confirming a DNS change has propagated to public resolvers.
  • Auditing SPF, DKIM and DMARC records before debugging email bounces.
  • Finding which CAs are authorized to issue certificates for a domain.
  • Getting the MX fallback order when mail delivery is flapping.

How it works

When you submit a name, the page calls the NetSight API, which sends DNS over HTTPS queries to public resolvers for the record types in the list above. The queries run in parallel and the answers are merged into one result. This is a recursive lookup: the resolver walks the DNS tree from the root to the authoritative nameservers on your behalf and returns the answer, so you see what an ordinary client on the internet would receive, not a direct read of your zone file.

Each answer carries a TTL (time to live) in seconds. It is the time a resolver may keep the record in its cache before it asks again. The value you see is what the resolver reported at that moment, so it can be lower than the TTL configured in the zone when the answer was served from a cache that had already counted down.

If the input is an IP address instead of a name, the tool builds the reverse name (for IPv4 the octets in reverse order under in-addr.arpa) and asks for its PTR record. The type chips only filter the display: clicking a chip hides the other record types in the result and runs the lookup again, and you can select several at once.

For a regular hostname the result also includes a DNSSEC status. It shows whether the zone is signed and whether the resolver could validate the chain of trust from the parent zone down to the answer.

How to read the results

The record cards

Every record type that returned data gets its own card with a counter in the corner. Types without data are not shown. If nothing at all comes back, the name has no records of the queried types, which is different from a name that does not exist at all.

  • A and AAAA: several addresses for one name are normal and usually mean round-robin or load balancing. A name that has an AAAA record but whose server does not listen on IPv6 causes slow or failing connections for clients that prefer IPv6.
  • CNAME: the alias target. A CNAME cannot coexist with other record types at the same name, which is why it is not allowed at the zone apex in standard DNS.
  • MX: the number in front of the host is the preference. The lowest number is tried first and higher numbers are fallbacks. Equal numbers share the load. The target of an MX record must be a hostname with address records, not an IP address and not a CNAME.
  • TXT: long values that were stored as several quoted strings are joined into one line. Look for v=spf1 (SPF), v=DMARC1 (on the _dmarc subdomain) and verification tokens. A domain should publish only one SPF record, because two separate SPF records cause an evaluation error.
  • NS: the delegated nameservers. They should match what the registry lists for the domain; a difference points to an unfinished migration.
  • SOA: shows the primary nameserver, the responsible mailbox (with the first dot standing for the at sign) and the serial. The serial increases with each zone change, so a different serial on different servers means they are out of sync.
  • CAA: each entry shows the value together with its meaning: issue allows normal certificates, issuewild allows wildcard certificates, iodef names a contact for violation reports. Without any CAA record every certificate authority may issue.
  • PTR: the reverse name of an address. Mail servers often compare it with the forward record, so a missing or mismatching PTR is a common reason for rejected mail.

The DNSSEC banner

Three states exist. "Not DNSSEC signed" is common and not an error by itself. "Signed and validated" means the chain of trust checks out. "Signed, but the resolver could not validate the chain" is the one that needs attention: the parent zone publishes a DS record, yet validation fails, for example because of expired signatures or a DS record that no longer matches the zone keys. Validating resolvers return an error for such a zone, so users may not be able to reach it at all.

Examples

Example 1: a mail domain

Enter example.com and select the MX and TXT chips. Two MX entries with preferences 10 and 20 mean that mail goes to the first host and falls back to the second when the first is unreachable. In the TXT card an entry beginning with v=spf1 lists the servers allowed to send mail for the domain, and it should end in a qualifier such as ~all or -all.

Example 2: a subdomain that points elsewhere

Enter www.example.com. If the CNAME card shows a target in a different domain and the A card shows the addresses of that target, the subdomain is an alias. A change at the target side then takes effect for this name as well, without touching your own zone.

Example 3: reverse lookup

Enter an address such as 192.0.2.10. If the PTR card shows a hostname, that is the name the address owner has registered for it. If the page reports no PTR record, the address has no reverse name. For a mail server this should be fixed, because the receiving side often treats a missing reverse name as a negative sign.

Common problems and how to fix them

  • The old value is still shown after a change. Resolvers keep an answer until its TTL runs out. Lower the TTL well before a planned change, make the change, and raise it again afterwards. Also check that you edited the zone at the nameservers that are actually listed in the NS records.
  • No records found. Check the spelling, make sure you entered a hostname without https:// or a path, and look at the right level: records for mail.example.com are not visible when you query example.com.
  • Mail is rejected although MX looks fine. Check SPF in the TXT card, the PTR of the sending address and whether the MX target resolves to an address.
  • Certificate issuance fails. Look at the CAA card. If CAA records exist, the authority you use must be listed in an issue entry, or for wildcards in issuewild.
  • DNSSEC shows a validation failure. Compare the DS record at the registrar with the current DNSKEY of the zone, and check that signatures have not expired. If you moved the zone to another provider, the DS record usually has to be removed or replaced.

Questions

Which DNS resolver does NetSight use?
Public DNS over HTTPS resolvers (Cloudflare 1.1.1.1 and Google 8.8.8.8) are queried at the edge. Answers are cached per TTL so repeated lookups are instant.
Does this check propagation across regions?
For a cross-region propagation view see the dedicated DNS propagation tool. This lookup goes to a single authoritative resolver per request.
Why is TXT truncated?
Large TXT records (>255 bytes) are returned as concatenated segments: we join them together for readability.
How long does a DNS change take to propagate?
It depends mainly on the TTL of the old record, because resolvers may keep the previous answer until that time has passed. With a TTL of 300 seconds most resolvers pick up the change within about five minutes, with 86400 seconds it can take up to a day. Changes to the nameserver delegation depend on the TTL at the parent zone and can take longer.
What is the difference between an A record and a CNAME record?
An A record maps a name directly to an IPv4 address, an AAAA record does the same for IPv6. A CNAME makes one name an alias for another name, and the resolver then looks up the target. A CNAME cannot share a name with other record types, so it is not used at the zone apex where NS and SOA records already exist.
How do I check my SPF, DKIM and DMARC records?
Select the TXT chip and look up the domain for SPF, which starts with v=spf1. DMARC is published at the _dmarc subdomain, for example _dmarc.example.com, and DKIM at selector._domainkey.example.com, where the selector name comes from your mail provider. Each of these is a TXT record, so you can read them all with this tool.
Why does the lookup show no result for a domain that works in my browser?
The name may only have records of types that were not returned, or you may have queried a different name than the one the browser uses, such as the apex instead of the www subdomain. A recent change can also still be hidden by cached answers. Clear the type filter and query the exact hostname from the address bar.
What does DNSSEC signed but not validated mean?
The parent zone announces that the domain is signed by publishing a DS record, but the resolver could not verify the signatures against the zone keys. Typical causes are expired signatures, a key rollover that was not completed, or a DS record left over after moving to a new DNS provider. Validating resolvers refuse to answer for such a zone, so it should be fixed quickly.
What do the MX preference numbers mean?
The preference is a priority value where the lowest number is used first. A sending server tries the host with the lowest number and moves on to higher numbers only if it cannot deliver. Hosts with the same number are used in a mixed order to spread the load.