How to test DNS resolution

Topic: Networking basics

Verify that hostnames resolve to the expected IPs using getent, dig, or nslookup. Use this when debugging 'can't reach host,' after changing resolvers or DNS records, or to confirm split-horizon or override. Test both the name and the reverse (IP to name) if needed.

Intent: How-to

Quick answer

  • getent hosts example.com uses system resolver and /etc/nsswitch.conf (same path as apps); dig example.com shows full response, resolver used, and TTL; nslookup is simpler but less detailed.
  • Test with a known name (e.g. google.com) first; then test the name you care about; compare A and AAAA if both IPv4 and IPv6 matter; check TTL and authority if debugging stale data.
  • If resolution fails: check /etc/resolv.conf and that the resolver is reachable (ping or dig @resolver); check firewall allows outbound UDP/TCP 53; try dig @8.8.8.8 name to bypass local resolver.

Prerequisites

Steps

  1. Use getent for system resolver

    getent hosts example.com; uses the same resolver and nsswitch as most apps; output is IP and name(s); getent ahosts for both A and AAAA. If this fails, apps will fail the same way.

  2. Use dig for detail

    dig example.com; shows QUESTION, ANSWER, AUTHORITY, resolver used, and TTL. dig @8.8.8.8 example.com queries that resolver directly; dig +short for just IPs.

  3. Test reverse lookup if needed

    dig -x 8.8.8.8 or getent hosts 8.8.8.8 (if nsswitch has hosts for reverse); use when debugging PTR or mail/forward checks.

  4. Compare and isolate

    If getent fails but dig @8.8.8.8 works: local resolver or /etc/resolv.conf is the problem. If both fail: firewall, routing, or the name really does not exist (NXDOMAIN).

Summary

Use getent hosts to test what the system resolver returns (same as most applications) and dig for detailed answers and to query a specific resolver. Use this to confirm DNS is working or to find where resolution fails.

Prerequisites

Steps

Step 1: Use getent for system resolver

getent hosts example.com
getent ahosts example.com

This uses the resolver configured in /etc/resolv.conf and the order in nsswitch.conf (e.g. files then dns). If it fails, typical apps will fail the same way.

Step 2: Use dig for detail

dig example.com
dig +short example.com
dig @8.8.8.8 example.com

dig shows the full response, which resolver was used, and TTL. Querying @8.8.8.8 (or another IP) bypasses the local resolver and tests that server directly.

Step 3: Test reverse lookup if needed

dig -x 8.8.8.8

Use when you need to verify PTR (reverse) records.

Step 4: Compare and isolate

  • getent fails, dig @8.8.8.8 works: Problem is local resolver config or reachability to the resolver.
  • Both fail: Firewall/routing blocking DNS, or the name does not exist (NXDOMAIN).

Verification

  • You can resolve a known name (e.g. google.com) with getent and dig; you can query a specific resolver with dig @IP and interpret a failure.

Troubleshooting

Temporary failure in resolution — Resolver overloaded or network glitch; retry; check resolver IP and that UDP/TCP 53 is allowed outbound.

Wrong IP returned — Stale cache (wait for TTL or flush); wrong authoritative data; or split-horizon DNS returning a different answer for your source.

Next steps

Continue to