is it DNS? wiki/Records/PTR: reverse pointer
Records

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.)

In one line:

7.2.0.192.in-addr.arpa.    PTR    neal.example.isitdns.net.
└── this IP, reversed ─┘   └type┘ └── has this name
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.

Read backwards, this is the IP 198.51.100.53 saying: my name is host1.example.com. It is the reverse of an A record, address to name instead of name to address.

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#

There is no PTR under example.isitdns.net: reverse zones are delegated by the RIR or the ISP that owns the address block, not by the owner of a forward zone, so a teaching zone cannot publish one. Cloudflare publishes a PTR for 1.1.1.2, and that is the live test used here. Unlike 1.1.1.1 (which reads the same backwards), the octet flip shows: 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 @1.1.1.1 -x 1.1.1.2 +short
security.cloudflare-dns.com.

-x is shorthand. Spelling the reverse name out by hand sends the identical query:

dig @1.1.1.1 2.1.1.1.in-addr.arpa PTR +short
security.cloudflare-dns.com.

nslookup ships on Windows and macOS, so it works where dig is not installed. It takes the address form or the reverse name:

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 nobody publishes PTRs for them. RFC 6303 section 4.2 lists all three reverse zones as locally served, so commands like dig @1.1.1.1 -x 198.51.100.53 come back NXDOMAIN from the resolver's own empty zone. Use these addresses 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 an IPv6 documentation prefix (RFC 3849; RFC 9637 added 3fff::/20 as a second one). It has no reverse zone; dig @1.1.1.1 -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.

See it live: 2.1.1.1.in-addr.arpa PTR on the front-page dig tool

The RFC: PTR is defined in RFC 1035 section 3.3.12. The in-addr.arpa tree is RFC 1035 section 3.5; the ip6.arpa nibble form is RFC 3596 section 2.5.

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 serve unrouted reverse space locally: RFC 6303 (Locally Served DNS Zones) standardizes an empty zone that answers SOA and NS at the zone name and NXDOMAIN for every name inside it, and BIND and Unbound ship those zones enabled by default. Details and the AS112 backstop are on reverse-dns.
  • 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#