DNS Query Basics: How Resolution Actually Works

Every time you type a domain into a browser or connect to a remote service, your device sends a DNS query. That query consists of a header with flags (QR, Opcode, AA, TC, RD, RA, etc.) and a question section that specifies the target domain and the record type you want. The resolver then follows a chain of queries—starting from the root, then the TLD, then the authoritative nameserver—to retrieve the final answer.

Recursive vs. Iterative Queries

Recursive queries are sent by clients to a resolver (e.g., your ISP’s DNS or a public resolver like 1.1.1.1). The resolver does all the work: it queries the root, the TLD, and the authoritative server, then returns either the answer or an error. Iterative queries are used between resolvers and nameservers. When a resolver asks a root server for example.com, the root responds with a referral to the .com TLD servers—it does not go any further. Understanding this distinction helps you interpret error codes and diagnose timeouts.

Common DNS Query Types – Expanded

Each DNS record type serves a specific purpose in network diagnostics. Below are the most frequently used types, their roles, and the problems they can reveal.

A Record (Address – IPv4)

The A record maps a domain to a 32-bit IPv4 address. It is the most fundamental query type. When an A query returns NXDOMAIN (non-existent domain), the domain is not configured for IPv4. A SERVFAIL response suggests the authoritative nameserver is unreachable or misconfigured. Use dig example.com A to verify that your web server’s IP is correct. For load-balanced services, multiple A records may appear; the resolver typically rotates among them.

AAAA Record (IPv6 Address)

Identical in function to the A record, but for 128-bit IPv6 addresses. As IPv6 adoption grows, checking AAAA records is critical when diagnosing connectivity issues on dual-stack networks. If a client prefers IPv6 but no AAAA record exists, the connection may fail or fall back to IPv4. Use dig example.com AAAA to confirm IPv6 reachability.

MX Record (Mail Exchange)

MX records specify the mail servers responsible for a domain and their priority numbers (lower values get tried first). A missing MX record means the domain cannot receive email. A configuration with only one low-priority server creates a single point of failure. Use dig example.com MX to list mail exchange servers. Common issues: incorrect hostnames (e.g., mail.example.com instead of mx1.example.com) or broken A/AAAA records for the MX targets (also known as “glue” consistency).

NS Record (Name Server)

NS records declare which nameservers are authoritative for a zone. When these records point to nameservers that do not exist or are not configured for the zone, delegation is broken. Use dig example.com NS to see the list. Also query the parent zone (e.g., .com) with dig example.com NS @a.gtld-servers.net to verify delegation matches the child zone. Mismatches cause intermittent outages.

TXT Record (Text)

TXT records store arbitrary text, but today they are dominated by email authentication: SPF, DKIM, and DMARC. Querying dig example.com TXT reveals SPF policies like v=spf1 mx include:_spf.google.com ~all. Missing or misconfigured TXT records lead to email spoofing vulnerabilities or legitimate messages landing in spam. Also check dig _dmarc.example.com TXT for DMARC policies.

CNAME Record (Canonical Name)

A CNAME record aliases one domain to another. For example, www.example.com may point to example.com. Use dig www.example.com CNAME to find the canonical hostname. Important: a CNAME cannot coexist with other records of the same name (RFC 1912). Overuse of CNAME chains increases resolution latency. Security note: an attacker who compromises the target domain can redirect your traffic.

SOA Record (Start of Authority)

The SOA record contains administrative metadata: the primary nameserver, the responsible email address, the serial number (critical for zone transfers), and timing values (refresh, retry, expire, minimum TTL). Query dig example.com SOA to verify the serial number matches across both primary and secondary servers. A mismatched serial is the most common cause of stale DNS data.

PTR Record (Pointer – Reverse DNS)

PTR records map IP addresses back to domain names, used in the in-addr.arpa or ip6.arpa zones. Email servers often reject mail from hosts whose PTR does not match the sending domain. Use dig -x 1.2.3.4 to check reverse DNS. Incorrect or missing PTR records are a frequent source of email deliverability problems.

SRV Record (Service Location)

SRV records define the hostname and port for specific services like SIP, LDAP, or XMPP. They follow the format _service._protocol.example.com. Query dig _sip._tcp.example.com SRV to see the priority, weight, and port. Troubleshooting SRV failures often reveals misconfigured port numbers or unresolvable target hostnames.

Practical DNS Querying with dig

The dig (Domain Information Groper) tool is the de facto standard for manual DNS diagnostics. Here are the most useful command patterns:

  • Simple lookup: dig example.com A – returns the IPv4 address and the TTL.
  • Specify record type: dig example.com MX or dig example.com SOA.
  • Query a specific resolver: dig @8.8.8.8 example.com A – bypasses your local resolver.
  • Trace the full resolution path: dig example.com +trace – shows iterative steps from root to authoritative.
  • Short output: dig +short example.com A – only the IP address, useful for scripts.
  • Reverse lookup: dig -x 93.184.216.34 – queries the PTR record.

Interpreting the response is key. The status field can be NOERROR (record found), NXDOMAIN (domain does not exist), SERVFAIL (server failure, often a timeout or misconfiguration), REFUSED (policy reject), or FORMERR (malformed query). The ANSWER SECTION shows the records retrieved; the AUTHORITY SECTION lists the nameservers responsible; the ADDITIONAL SECTION often contains glue records or IP addresses of those nameservers.

Security Implications of DNS Query Types

DNS queries are plaintext by default, making them visible to network adversaries unless DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) is used. Specific record types have security considerations:

  • TXT records for SPF, DKIM, and DMARC: These are the backbone of email security. A single missing or overly permissive SPF record (e.g., +all) allows anyone to send mail as your domain. Query your own domain regularly with dig YOURDOMAIN TXT and dig _dmarc.YOURDOMAIN TXT.
  • CNAME and redirection attacks: If a CNAME target domain expires or is taken over by an attacker, every alias pointing to it becomes a phishing vector. Always check that target hostnames are controlled and have valid A/AAAA records.
  • NS record spoofing: A misconfigured parent zone could point to malicious nameservers. Use dig +trace to check each delegation step.

DNSSEC (DNS Security Extensions) is designed to protect against forged answers. Query with +dnssec to see RRSIG and DNSKEY records. If your resolver supports validation, responses will include the ad flag (authentic data).

Troubleshooting with DNS Queries – A Step-by-Step Scenario

Suppose users cannot access example.com and email is failing. Use the following methodology:

  1. Check A/AAAA: dig example.com A and dig example.com AAAA. If NXDOMAIN, the domain may be expired or removed. If SERVFAIL, try querying directly from a public resolver: dig @1.1.1.1 example.com A.
  2. Verify delegation: dig example.com NS and compare with the parent zone: dig example.com NS @a.gtld-servers.net. If they differ, the domain is misdelegated.
  3. Inspect SOA: dig example.com SOA. Check the serial number on both primary and secondary nameservers. If serials mismatch, zone transfers are failing.
  4. Test MX: dig example.com MX. Note the target hostnames (e.g., mail.example.com). Then test each target: dig mail.example.com A. If the mail server’s IP does not resolve, email cannot be delivered.
  5. Confirm reverse DNS: dig -x <mail_server_ip>. The PTR record should match the FQDN of the mail server. Many receiving servers reject mail if this is missing.
  6. Check TXT records for email auth: dig example.com TXT for SPF, and dig _dmarc.example.com TXT. Look for syntax errors or missing “v=” tags.

By systematically running these queries, you isolate whether the problem is in delegation, zone content, or email configuration.

Conclusion

Mastering DNS query types transforms abstract network diagnostics into precise, actionable steps. The A, AAAA, MX, NS, TXT, CNAME, SOA, PTR, and SRV records each reveal a different layer of your infrastructure’s health. Tools like dig and nslookup put the entire DNS ecosystem at your fingertips—understand the response sections and error codes, and you can resolve most connectivity and email problems in minutes. Incorporate DNSSEC validation and regular TXT record auditing to keep your domain secure. For further reading, consult RFC 1035 on DNS implementation and the IANA DNS parameter registry. With these skills, you ensure reliable, secure name resolution across your network.