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_dmarcsubdomain) 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:
issueallows normal certificates,issuewildallows wildcard certificates,iodefnames 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 formail.example.comare not visible when you queryexample.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
issueentry, or for wildcards inissuewild. - 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.