Domain Name System (DNS)

DNS configurations rely on specific record types: A records map hostnames to IPv4 addresses, AAAA records map hostnames to IPv6 addresses, CNAME records alias one domain name to another, MX records define mail servers for a domain, TXT records hold arbitrary configuration metadata (SPF, DKIM, domain verification strings), and PTR records map an IP address back to a hostname — the reverse of an A record.

A standard forward lookup (name to address) is what most people mean by "DNS lookup," but reverse DNS (address to name, via PTR records under the special in-addr.arpa or ip6.arpa zones) matters specifically for mail server reputation: most receiving mail servers check that a sending IP's PTR record resolves to a hostname, and that hostname's own A record resolves back to the same IP, before accepting mail. A mismatch is a strong spam signal.

WHOIS is a separate, older protocol from DNS resolution itself: it looks up registration metadata for a domain (registrar, registration and expiration dates, sometimes registrant contact details subject to privacy redaction) rather than resolving the domain to an address. It is queried independently of the DNS resolution path but is frequently used alongside it when investigating a domain.

Recursive resolvers query root, TLD, and authoritative name servers in sequence to retrieve the appropriate resource records for a forward lookup, caching results according to each record's TTL to reduce repeated lookups.

A common real-world task is confirming why mail from a domain is being marked as spam, or why a service isn't resolving as expected. Start with the DNS Lookup tool to pull the domain's current A, AAAA, MX, and TXT records directly, confirming the records that should exist actually do, and point where expected.

If the issue is mail-related, use Reverse DNS Lookup on the sending mail server's IP address to confirm it resolves to a hostname, and check that hostname's forward A record points back to the same IP. A broken or missing PTR record is one of the most common reasons legitimate mail gets rejected or flagged.

If the domain itself is unfamiliar or you need to confirm who controls it — before trusting a redirect, checking a potential typosquat, or verifying an infrastructure handoff during a migration — use the WHOIS Lookup Parser to pull registrar and registration-date information into structured fields rather than parsing raw WHOIS text output by hand.

For domains behind a CDN or load balancer, cross-reference the resolved A/AAAA records against the provider's documented IP ranges, and use the IPv4 Subnet Calculator to confirm whether a resolved address actually falls within the expected published range.

Mistake: pointing an MX record at a CNAME instead of directly at a hostname with its own A/AAAA record. RFC 1035 and RFC 2181 both prohibit this — mail servers that strictly enforce the RFC will silently fail to deliver, producing confusing intermittent delivery problems rather than a clear error.

Mistake: not lowering a record's TTL before a planned migration. If a record's TTL is 86400 seconds (24 hours) and you cut over to a new IP without lowering it in advance, resolvers that cached the old value keep using it for up to 24 hours after the change, causing a mixed-traffic period that's hard to diagnose. Fix: lower the TTL to a short value (for example 300 seconds) at least one full TTL cycle before the planned change, then restore it afterward.

Troubleshooting: if a service works from some networks but not others shortly after a DNS change, this is almost always propagation lag from resolver caching, not a configuration error — different resolvers cache independently and converge on the new value once each one's cached TTL expires, not simultaneously.

Troubleshooting: if outbound mail is being rejected specifically (not just marked as spam), check the PTR record for the sending IP first — many receiving servers reject mail outright, before content filtering even runs, if the reverse lookup doesn't resolve or doesn't match the claimed sending hostname.

The core DNS specification is split across RFC 1034 (concepts and facilities) and RFC 1035 (implementation and specification), both from 1987 and still the foundation of how DNS resolution works today.

DNS-over-HTTPS (DoH) is defined by RFC 8484, encrypting DNS queries inside standard HTTPS traffic to prevent on-path observation or tampering by network intermediaries.

AAAA records for IPv6 are defined by RFC 3596. Common DNS configuration mistakes, including the MX-to-CNAME error described above, are catalogued directly in RFC 2181 and the older but still-referenced RFC 1912.

WHOIS itself is defined by RFC 3912, though in practice registrar and registry WHOIS output varies significantly in format since the RFC specifies the protocol, not a strict response schema — this is why a dedicated parser is more reliable than manually reading raw output.

Use an A record when you need to point a hostname directly at a specific IPv4 address you control and expect to manage yourself. Use a CNAME when you need to alias a hostname to another hostname whose IP may change without your involvement (common for CDN and SaaS endpoints) — but never at your domain's root/apex, since most authoritative servers don't permit a CNAME to coexist with other records at that level. See the A vs CNAME comparison for the full tradeoff.

Use an AAAA record whenever you also maintain an A record for the same host and have IPv6 connectivity available — modern dual-stack practice is to publish both rather than choosing one, so resolvers and clients can use whichever protocol they support. See the A vs AAAA comparison for when IPv6-only or dual-stack publishing makes sense for your setup.

If you're deciding whether a networking problem is a DNS issue or an IP-routing issue, resolve the hostname first — if it resolves to the correct, expected address but connectivity still fails, the problem is routing, not DNS. See the DNS vs IP Routing comparison for how to separate these two failure domains during troubleshooting. Once you've confirmed DNS itself is resolving correctly, the Networking & Infrastructure hub covers the subnet, routing, and addressing fundamentals needed to diagnose what happens next.