Visual RFC.
ALL RFCs / RFC 2317
Read the RFC ↗
RFC 2317 / CLASSLESS REVERSE DNS

Plan the names and operational dependencies

05

The aliases keep reverse lookup working even when PTR data lives elsewhere. That flexibility still depends on the delegating parent and on a consistent naming plan.

RFC 2317 · § 5.2EXAMPLE
4 / 4
Plan the names and operational dependenciesThe aliases keep reverse lookup working even when PTR data lives elsewhere. That flexibility still depends on the delegating parent and on a consistent naming plan. In this chosen broken configuration, the child PTR exists but the ordinary reverse owner has no connecting CNAME. The resolver cannot discover it merely by knowing the address. No specific DNS error code is asserted; missing-data and server-failure details depend on the configuration.Keep the operational dependencies visibleParentChildOrdinary owner: missing CNAMENo connecting aliasChild PTR exists but is not discoveredAn extra operational dependency · §6RFC2317 · fictional example · schematic
04
Check both administrative sides

In this chosen broken configuration, the child PTR exists but the ordinary reverse owner has no connecting CNAME. The resolver cannot discover it merely by knowing the address. No specific DNS error code is asserted; missing-data and server-failure details depend on the configuration.

Source for this drawing: RFC 2317 · Read RFC section 5.2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

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

KEY POINT

Section 5.2 permits targets in another DNS subtree, for example 129.b.example. The original IN-ADDR.ARPA traversal and correct parent CNAME remain necessary.

  • Section 5.2 permits targets in another DNS subtree, for example 129.b.example. The original IN-ADDR.ARPA traversal and correct parent CNAME remain necessary.
  • Section 5.1 recommends parent authorities also run as secondaries for child zones to help certain older name-server behavior. This is historical interoperability advice, not a new universal MUST for modern servers.
  • Section 5.3 warns against repeating this scheme at nested allocations and producing CNAME-to-CNAME chains, which can be less robust. This operational warning is not a general claim that DNS forbids every CNAME chain.
  • Section 6 notes an extra operational dependency compared with having one’s own /24. This mechanism adds no authentication or encryption and does not remove parent-side coordination.
DETAILS

Fictional documentation addresses and .example names. Zone snippets omit TTLs, SOA timers and other deployment settings. This is DNS delegation, not a routing change or proof of identity.

Read the RFC section ↗

All chapters in RFC 2317

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 ↗