DNS is the directory system that connects human-readable domain names with network services. When a website, API, or email service behaves unexpectedly, DNS is often the fastest place to look for an explanation. The key is knowing what each record means and what a lookup…

DNS is the directory system that connects human-readable domain names with network services. When a website, API, or email service behaves unexpectedly, DNS is often the fastest place to look for an explanation. The key is knowing what each record means and what a lookup result can actually prove.

What WebLens queries

The WebLens DNS Lookup checks common public record types including A, AAAA, CNAME, MX, NS, TXT, and SOA. If the supplied target is an IP address, the tool performs a reverse lookup and reports a PTR result when one is available.

The records you will see

A records map a hostname to an IPv4 address. AAAA records provide IPv6 addresses. CNAME records alias one hostname to another. MX records identify mail servers and include priority values. NS records identify authoritative name servers. TXT records can carry public text data, including email authentication policies. SOA contains authority and zone timing information.

A practical troubleshooting sequence

  1. Run the WebLens DNS Lookup for the exact domain.
  2. Check whether expected A or AAAA records exist.
  3. If a service uses an alias, inspect CNAME-related configuration.
  4. For email problems, check MX records and then investigate mail authentication separately.
  5. If you are investigating delegation, compare NS records with the DNS provider you expect.

Example: a website migration

Suppose a site moved to another host. You update the A record, but some visitors still reach the old server. DNS caches can retain earlier answers until their TTLs expire. Multiple A records can also intentionally distribute traffic. A lookup gives you the records visible from WebLens; it does not tell you what every resolver has cached.

Example: email stops arriving

If mail suddenly stops, an MX lookup is a focused first check. No MX records, an unexpected destination, or incorrect priority can explain delivery problems. A correct MX record does not prove that the receiving server accepts a particular message. SPF, DKIM, DMARC, reputation, SMTP responses, mailbox state, and filtering live elsewhere in the mail path.

Why DNS answers differ

Resolvers cache answers, providers can use geographic routing, and DNS records can change independently across authoritative servers during propagation. WebLens reports what its server can retrieve through its resolver at check time. It is a useful external snapshot rather than a universal view of every resolver’s cache.

Reverse DNS is different

When you enter an IP address, WebLens attempts a reverse lookup and reports the PTR name if one exists. PTR records are controlled separately from forward A and AAAA records. A missing PTR does not mean the IP is broken.

Limits to keep in mind

Public DNS records are only one layer of name resolution. Split-horizon DNS, private zones, VPN environments, local hosts files, resolver policies, and cached data can all produce results that differ from a simple public lookup.

Want to see the records directly? Run the WebLens DNS Lookup and use the record types to build a clear picture of how the service is connected.

Propagation is not the same as an error

After a DNS change, different resolvers can legitimately return different answers for a period because they cache records according to TTL values. That is why a change visible in one location may not appear everywhere immediately. Before declaring a DNS migration broken, compare the authoritative zone with several public resolver observations and check the record TTL.

Also remember that DNS records can be intentionally different. A CDN may use geographic answers, while an internal corporate resolver may use split-horizon DNS. A public WebLens lookup cannot see private answers that are available only inside a network.

Pair DNS evidence with the service layer

If DNS returns the expected address but the website fails, move to HTTP status and TLS. If DNS returns an unexpected address, stay at the DNS layer until the record and delegation are understood. This prevents an application symptom from being mistaken for a DNS cause.