is it dns? / wiki ← back to the live monitor

PTR: reverse pointer

An IP → a name. The record type reverse zones (in-addr.arpa, ip6.arpa) exist to serve. What dig -x <ip> returns. (Reverse zones also hold the usual SOA/NS plumbing, and RFC 2317 CNAMEs; PTR is what you query them for.)

Type number12
RFC1035
RDATAA single fully-qualified domain name
Lives inin-addr.arpa or ip6.arpa zones

What it holds#

A single FQDN pointing back from an IP address. Background and the zone-structure mechanics are on the reverse-DNS page: this page just covers the record itself.

53.100.51.198.in-addr.arpa.   PTR   host1.example.com.

When to use it#

  • Mail servers. Receiving mail servers do a forward-confirmed reverse DNS (FCrDNS) check: the forward record of the PTR target must point back to the original IP. Without a matching PTR, your mail is heavily penalized. See email-records for how PTR fits into the broader mail-authentication picture.
  • SSH and log enrichment. Daemons that resolve client IPs for their logs show names instead of bare IPs. Note that sshd only does this with UseDNS yes; the default has been no for years (sshd_config(5)).
  • Network observability. Queries are much more readable when client IPs resolve to host names; many dnstap and flow-log pipelines enrich messages with reverse-DNS names where available.
  • Spam scoring. Receiving-side filters score "no PTR" or "PTR doesn't match forward" as suspicious.

When not to use it#

  • For aliasing or load balancing: PTR is one-to-one by convention. Multiple PTRs for one IP work technically but confuse half the tools that consume them.
  • In forward zones, with one real exception: DNS-Based Service Discovery (RFC 6763) legitimately publishes PTR records under forward names like _ipp._tcp.example.com to enumerate service instances. Outside DNS-SD, keep PTR in the .arpa reverse trees.

dig example#

Cloudflare publishes a PTR for 1.1.1.2 that you can use as a live test. Unlike 1.1.1.1 (which reads the same backwards), the octet flip shows here: the trailing .2 of 1.1.1.2 becomes the leading label of 2.1.1.1.in-addr.arpa. See nslookup-and-dig for a full comparison of both tools.

dig -x 1.1.1.2 +short
security.cloudflare-dns.com.
dig 2.1.1.1.in-addr.arpa PTR +short
security.cloudflare-dns.com.
nslookup 1.1.1.2 1.1.1.1
2.1.1.1.in-addr.arpa	name = security.cloudflare-dns.com.

Authoritative answers can be found from:
nslookup -type=PTR 2.1.1.1.in-addr.arpa 1.1.1.1
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
2.1.1.1.in-addr.arpa	name = security.cloudflare-dns.com.

Authoritative answers can be found from:

Output shown is from a current BIND nslookup (9.18): the address form prints the bare PTR line, while the explicit -type=PTR form adds the Server:/Address: banner and the Non-authoritative answer: header. Older builds, including the BIND 9.10 nslookup that macOS ships, print the banner and header for both forms. The dangling Authoritative answers can be found from: line with nothing under it is normal.

RFC 5737 documentation addresses (192.0.2.x, 198.51.100.x, 203.0.113.x) are not routed and have no reverse zones. Commands like dig -x 198.51.100.53 return NXDOMAIN; use them in zone-file examples only, not as live lookups.

IPv6: the eye-watering form. dig rewrites the address into the reverse name before sending the query. Use a real routed address (not a documentation address) so the example actually resolves:

dig @1.1.1.1 -x 2606:4700:4700::1111 +short
one.one.one.one.

The name dig sends is every nibble of the expanded address, reversed, with .ip6.arpa appended:

1.1.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.4.0.0.7.4.6.0.6.2.ip6.arpa
nslookup 2606:4700:4700::1111 1.1.1.1
1.1.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.4.0.0.7.4.6.0.6.2.ip6.arpa	name = one.one.one.one.

Authoritative answers can be found from:

2001:db8:: is the RFC 3849 documentation prefix. It has no reverse zone; dig -x 2001:db8::1 returns NXDOMAIN. Use it in static zone-file diagrams only, not as a live command example.

See reverse-dns for why it looks like that.

DoH query (HTTPS)#

DoH is DNS-over-HTTPS. The application/dns-json format is a Cloudflare/Google convention, not part of RFC 8484 itself (that defines only the binary application/dns-message type). Cloudflare and Google both answer it; most other public resolvers, Quad9 and OpenDNS included, do not:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=2.1.1.1.in-addr.arpa&type=PTR' \
  | jq .Answer
[
  {
    "name": "2.1.1.1.in-addr.arpa",
    "type": 12,
    "TTL": 110,
    "data": "security.cloudflare-dns.com."
  }
]

The TTL field counts down as the resolver's cache entry ages, so your number will differ run to run.

nslookup cannot do DoH/DoT/DoQ. On Windows, Resolve-DnsName uses the system-configured DoH resolver when the OS is set up for encrypted DNS; there is no -DnsOverHttps parameter and it does not accept an arbitrary endpoint as -Server. To probe a specific DoH service, use the curl example above. See dot-doh for encrypted-DNS options that work from the command line.

Gotchas#

  • One PTR per IP, in practice. RFC 1035 allows multiples; tooling expects one. Pick a canonical hostname per IP and stick with it.
  • PTR must be in the right zone. A PTR for 198.51.100.20 lives in 100.51.198.in-addr.arpa. If you've stood up 51.198.in-addr.arpa but never delegated 100.51.198.in-addr.arpa, resolution stops at the parent, which knows nothing about the child names, and the PTR is invisible.
  • FCrDNS asymmetry. The PTR points to a name. That name's A or AAAA record must point back to the original IP. If forward and reverse disagree, mail filters and security tools treat the host as suspicious.
  • RFC 1918 reverse leaks. A wide-open recursive resolver may forward queries for 192.168.x.x.in-addr.arpa to the Internet, leaking your internal addressing. Configure the resolver to answer NXDOMAIN for unrouted reverse space locally; RFC 6303 (Locally Served DNS Zones) standardizes this, and BIND and Unbound ship those "empty zones" enabled by default. Details and the AS112 backstop are on ip-address-spaces.
  • Public reverse not under your control. Reverse DNS for a public IP is delegated by your RIR/ISP, not your zone. To get a custom PTR for a static public IP, your ISP usually has to do it.

See also#