Visual RFC.
ALL RFCs / RFC 1034
Read the RFC ↗
RFC 1034 / NAMES & RECORDS

Reverse lookups

11

IPv4 reverse lookup uses an ordinary DNS question in the IN-ADDR.ARPA tree.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

RFC 1034 · § 5.2.1EXAMPLE
4 / 4
Reverse lookupsFour IPv4 octets visibly reverse positions before a PTR query is assembled.Worked example: IPv4 reverse name1920220202019220.2.0.192.in-addr.arpa.QTYPE = PTRPTR → host.example.org.
04
Return naming information.

Treat this as DNS data rather than authentication.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

Reverse the address labels, then query PTR.

  • The reverse name for 192.0.2.20 is 20.2.0.192.in-addr.arpa.
  • Reverse DNS uses standard PTR queries, not the historic optional inverse-query opcode.
  • A reverse answer does not by itself prove who controls a connection or that forward and reverse mappings agree.
DETAILS

This RFC predates IPv6 reverse lookup. The example uses a documentation-only IPv4 address.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. The name tree
  2. Resource records
  3. Delegation & glue
  4. Iterative resolution
  5. Recursive resolution
  6. Caches & TTL
  7. Aliases
  8. Missing names & failures
  9. Wildcard synthesis
  10. Zone maintenance
  11. Reverse lookups
  12. Transport & historical scope

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗