To look up the hostname published for an IP address, run dig -x IP_ADDRESS +short. For example, dig -x 203.0.113.25 +short asks DNS for a PTR record and prints a returned name if one exists. For the full response—including status, resolver, TTL, and answer details—omit +short: dig -x 203.0.113.25. A missing result is not necessarily a network failure: many IP addresses have no PTR record.
What a reverse DNS lookup does
A forward DNS lookup maps a hostname to an IP address, usually through an A record for IPv4 or an AAAA record for IPv6. A reverse lookup asks DNS for a hostname associated with an address. The usual answer is a PTR record. It is a DNS query, not a separate networking protocol, and it returns only the name published for that address—not verified ownership or identity. For background on DNS and its original inverse-query mechanism, see RFC 1035.
How reverse names are formed
IPv4 reverse names reverse the address octets and append in-addr.arpa. For example, 203.0.113.25 becomes 25.113.0.203.in-addr.arpa. You can query it explicitly with dig 25.113.0.203.in-addr.arpa PTR, but dig -x 203.0.113.25 constructs the name for you.
IPv6 reverse names use reversed hexadecimal nibbles under ip6.arpa. The expanded address produces a long name, so use dig -x 2001:db8::25 rather than building it manually. The format is specified in RFC 3596.
Which Linux command should you use?
| Goal | Command | What it tests |
|---|---|---|
| Quick DNS answer | dig -x IP_ADDRESS +short |
DNS query; prints a concise answer |
| Inspect DNS status and response | dig -x IP_ADDRESS |
DNS query with status, answer, resolver and other details |
| Ask a particular resolver | dig @DNS_SERVER -x IP_ADDRESS |
DNS query sent to the named server |
| Readable DNS response | host IP_ADDRESS |
DNS query with compact human-readable output |
| Use a familiar DNS utility | nslookup IP_ADDRESS |
DNS query; generally less diagnostic detail than dig |
| Test systemd-resolved | resolvectl query IP_ADDRESS |
Resolution through systemd-resolved, when present and active |
| Test the system host lookup path | getent hosts IP_ADDRESS |
Name Service Switch (NSS), which may consult local files and other configured sources |
dig is the best default for DNS troubleshooting because it exposes the response and lets you choose a resolver. Its -x option performs a reverse lookup. See the BIND 9 command reference and dig manual. Use getent when you need to reproduce what applications using the system lookup path may see; NSS source order is configured in /etc/nsswitch.conf.
Run a lookup and choose the resolver
- Get a concise result:
dig -x 203.0.113.25 +short. The example address is reserved for documentation, so it is not a promise of a live PTR result. - Inspect the full DNS response:
dig -x 203.0.113.25. The default resolver is determined by the machine’s DNS configuration. - Compare a specific resolver:
dig @1.1.1.1 -x 203.0.113.25. The general form isdig @DNS_SERVER -x IP_ADDRESS. You can use a resolver hostname or address. - Show only the answer section:
dig -x 203.0.113.25 +noall +answer. This is more informative than+shortwhile remaining compact. - Try other tools if relevant:
host 203.0.113.25ornslookup 203.0.113.25. To specify a resolver, usehost 203.0.113.25 1.1.1.1ornslookup 203.0.113.25 1.1.1.1.
For IPv6, the same shorthand works: dig -x 2001:db8::25. To request the systemd resolver’s view, use resolvectl query 203.0.113.25; to inspect its configuration, use resolvectl status or resolvectl dns. These commands depend on systemd-resolved being installed, running, and integrated with the system. Its query behavior and available result metadata are described in the resolvectl manual.
Read the response before deciding what failed
Without +short, dig shows a status line, answer and authority sections, and the responding server. A successful PTR answer appears in the answer section with the queried reverse name, a TTL, the type PTR, and the returned hostname. Names and TTLs can change; a sample response is not a permanent mapping.
NOERRORwith a PTR answer: The queried resolver returned a record.NOERRORwith no answer: The query completed, but there is no usable PTR answer in the response. Check the authority section and resolver before concluding why.NXDOMAIN: The queried reverse-DNS name does not exist according to that resolver.SERVFAIL: The resolver could not complete the lookup. Causes can include resolution or DNSSEC validation problems; this is not the same as a confirmed missing record.REFUSED: The server declined the query.- Timeout: The resolver did not reply in time. Check connectivity, DNS policy, firewall rules, and the server address.
+short hides the status, responding server, TTL, authority information, and other diagnostic context. Use it for a quick display or script only after deciding that those details are not needed. If DNS can use either UDP or TCP in your environment, a firewall that blocks DNS traffic may cause timeouts or incomplete troubleshooting results.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Why DNS tools and applications can disagree
dig, host, and nslookup query DNS. By contrast, getent hosts follows the system’s Name Service Switch configuration, which can consult /etc/hosts, DNS, mDNS, LDAP, or other sources depending on installed modules and /etc/nsswitch.conf. For example, a hosts: files dns entry checks local files before DNS, so getent or an application can return a local mapping that dig does not. See the getent manual and nsswitch.conf manual.
resolvectl queries through systemd-resolved, when the service is in use. That service can apply per-interface DNS servers and routing, caching, DNSSEC validation, local host-file data, and local protocols. It therefore may not match a direct query to a server chosen with dig @SERVER. The systemd resolver-client documentation describes how resolver clients can receive local-source and protocol information.
Rank #3
Likewise, /etc/resolv.conf does not always reveal the upstream provider. On some systems it points to a local stub such as 127.0.0.53, which forwards queries rather than acting as the external DNS provider. Inspect resolvectl status or the active network manager’s DNS settings to understand the configured upstreams.
Troubleshoot a missing or unexpected hostname
- Check the input. Confirm that you have an IP address, not a port, hostname, URL, or CIDR network. If you are checking a live connection,
ss -tnpcan show TCP peers. - Capture the full DNS result. Run
dig -x IP_ADDRESSand note the status, answer section, server, and whether the query timed out. - Compare resolvers when appropriate. Try
dig @1.1.1.1 -x IP_ADDRESSanddig @8.8.8.8 -x IP_ADDRESS. Public resolvers may not know private reverse zones. Different results can reflect cache state, delegation, DNSSEC validation, or resolver policy. - Compare DNS with the system path. Run
getent hosts IP_ADDRESSand, where applicable,resolvectl query IP_ADDRESS. If results differ, inspectgrep '^hosts:' /etc/nsswitch.conf,cat /etc/hosts, andcat /etc/resolv.conf. - Check address families separately. Query the IPv4 and IPv6 addresses independently. A missing PTR for one does not establish a problem with the other.
- Check a returned name forward. Substitute the returned hostname in
dig +short hostname.example.com Aanddig +short hostname.example.com AAAA, then compare the addresses with the original IP. - If you administer the reverse zone, trace delegation. Run
dig +trace -x IP_ADDRESSto follow delegation from the DNS root. This may be blocked or less useful on restricted networks, and it is not the same as asking a recursive resolver for its cached answer.
Private addresses and split DNS
Private addresses such as 10.0.0.1, 172.16.0.1, and 192.168.1.1 usually need an organization’s internal reverse zone. A public resolver generally cannot return a meaningful internal PTR record. Ask the internal DNS server directly, for example dig @10.0.0.53 -x 10.20.30.40. Internal and external resolvers may intentionally return different results under split-horizon DNS, so record which server answered.
Stale data, validation, and slow lookups
Resolvers cache DNS data according to TTLs and may temporarily disagree while caches update. A validating resolver may return SERVFAIL for a broken DNSSEC chain even when a non-validating resolver returns an answer. A missing or slow PTR can also delay software that performs reverse lookups while logging or processing connections; avoid making reverse DNS a blocking dependency unless it is required.
Verify a reverse result—and understand its limits
If a PTR lookup returns mail.example.com, query that name’s A and AAAA records and check whether they include the original address. This forward-confirmed reverse-DNS check catches inconsistencies; it does not authenticate a host. PTR data can be absent, stale, misleading, or changed by the party controlling the reverse zone. DNSSEC can help authenticate DNS data, but it does not establish the legal or operational identity of a machine. The security considerations in RFC 3596 caution against treating DNS information as inherently trustworthy.
Do not rely on PTR alone to trust an SSH client, email sender, crawler, or security event. Use application-level authentication, TLS certificate validation, and appropriate network or ownership checks for the decision at hand.
Setting or fixing a PTR record
A PTR record is controlled by the party responsible for the reverse-DNS zone, usually the address provider or an administrator to whom reverse control has been delegated. If you need a PTR for a cloud or hosted address, use the provider’s reverse-DNS settings or contact its support; changing the forward zone you own does not automatically change the reverse record. Dynamic residential addresses may not allow custom PTR records.
Best Value
For a delegated block, verify that the reverse zone is correctly delegated. Smaller IPv4 allocations may need classless reverse delegation, described in RFC 2317. After a change, query the responsible authoritative service and a recursive resolver; cached answers may persist until their TTL expires.
Use reverse lookup in a program
For C software, getnameinfo() converts a socket address into a hostname and service name. The NI_NAMEREQD flag requires a hostname and reports an error if one cannot be found. This is the protocol-independent counterpart to address-to-name resolution; see the getnameinfo manual. As with command-line lookups, application behavior depends on the system’s resolver configuration.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
