Summary

  • RFC 5158 is a March 2008 Informational specification for delegating reverse DNS beneath the 6to4 reverse tree.
  • A 6to4 site prefix placed an external IPv4 address inside 2002::/16, yielding a site /48 whose reverse zone could be derived mechanically.
  • The proposal used a one-level conventional delegation beneath 2.0.0.2.ip6.arpa instead of treating a web database as the public naming system.
  • A client could request only the zone corresponding to the 6to4 source address from which it contacted the service.
  • The nominated primary and secondary servers had to be online, reachable, authoritative, and consistent in SOA and NS data before activation.
  • HTTPS protected the request channel and reduced impersonation and proxy-cache hazards, but did not establish the requester's administrative mandate.
  • RFC 5158 explicitly described address-based authentication as rudimentary and potentially spoofable.
  • A host inside a site could change delegation without the administrator's knowledge unless local access controls or firewalls prevented it.
  • When a dynamically assigned IPv4 address moved, the new holder could encounter reverse state created by the previous site.
  • Low TTLs and periodic checks limited stale-state duration; they did not convert changing address custody into durable identity.
  • The RFC warned that reverse DNS presence or absence was not reliable validation of an address-domain relationship.
  • Assurance must keep source observation, address custody, administrator authorization, server readiness, delegation state and PTR assertions as distinct receipts.

A derived zone was a narrow technical entitlement

6to4 turned an externally reachable IPv4 address into part of an IPv6 prefix. The address occupied 32 bits after 2002::/16, making one /48 for the site. That arithmetic supplied a useful containment rule: a request observed from a 6to4 source could be limited to the reverse zone derived from the embedded IPv4 value.

This was not ordinary IPv4 reverse delegation copied into IPv6. The holder of an IPv4 /32 often had no corresponding delegation boundary in in-addr.arpa, and a 6to4 edge could obtain IPv6 connectivity without a conventional IPv6 provider relationship. RFC 5158 therefore located a registration service above the derived zones and had it create normal DNS delegations at the /48 boundary.

The result was deliberately modest. A source could not ask for an unrelated site's zone. It could demonstrate current packet-level reachability from an address that mapped to the requested zone. Neither fact identified the human or organisation entitled to make a lasting administrative decision for every system behind that site.

Readiness checks proved that DNS machinery existed

Before installing a delegation, the service was to query the nominated authoritative servers. The primary and at least one secondary had to be online and reachable. They had to answer authoritatively for the zone, expose the same SOA, and publish identical NS RRsets. These tests prevented an obviously incomplete request from becoming a broken parent delegation.

They were important operational evidence. They showed that the proposed child zone existed at that moment and that its servers agreed about the delegation-facing configuration. They did not inspect the institutional process that selected those servers. Nor did they certify the truth of a PTR record inside the zone. Two servers can agree perfectly on a false, obsolete or unauthorised assertion.

Conflating readiness with authority changes the meaning of the receipt. “The servers answered consistently” is a reproducible observation. “The site administrator approved this reverse namespace” requires a separate chain: principal, mandate, scope, time and revocation.

HTTPS secured a session, not a mandate

RFC 5158 expected an HTTPS interface. Encryption and server authentication protected the transaction from casual interception, modification and confusing cache behaviour. The mechanism also narrowed requests by checking the client's 6to4 source address.

Yet the document calls this address-based authentication rudimentary. Source addresses can be spoofed in some conditions, and a client already inside the site can possess a legitimate 6to4 source without holding DNS authority. The specification explicitly notes that such a client might alter the delegation without the administrator knowing. Local filtering and access-control policy were left to the site.

This is the governance seam. Transport security answers which endpoint protected the exchange. Address matching answers whether the request originated within a technical boundary. Neither answers who was authorised to bind the institution to a nameserver set. A clean audit must retain all three questions instead of allowing a successful HTTPS response to stand in for consent.

Dynamic custody could hand a stranger yesterday's story

The embedded IPv4 address looked stable inside the zone name, but many external IPv4 assignments were dynamic. After reassignment, the same derived 6to4 /48 could belong to a different site. The new holder might see an existing delegation or PTR data created by the previous holder, or might replace them while caches still retained the old story.

RFC 5158 used low TTLs and lifecycle checks to reduce this exposure. A service could retest the delegated servers every thirty days, warn on failure, retry after fourteen days, and remove the delegation after a second failure. The IPv4 address controller could also request that registration be blocked.

Those controls manage stale infrastructure. They do not prove continuity of ownership between checks. A healthy authoritative server can continue answering after the underlying address has changed hands. A failed server can belong to the same administrator. Liveness, custody and authority are separate variables even when one workflow observes them together.

Reverse DNS was explicitly not identity evidence

RFC 5158 cautioned against drawing conclusions from a reverse mapping. The presence of a PTR record does not validate a relationship between a domain name and an IP address; its absence does not disprove one. Forward-confirmed reverse DNS can add another test, but it still reports configured naming state rather than legal identity, operational responsibility or user intent.

That warning matters because reverse names are routinely pulled into logs, access rules and incident reports as if they were attestations. A self-service delegation can make the namespace useful without making every label authoritative beyond DNS. Its correct evidentiary value is bounded: a parent delegated a derived zone to a tested nameserver set under a stated policy at a stated time.

Later deprecation changes context, not the historical lesson

The service design belonged to the 6to4 transition era. Later operational guidance documented recurring 6to4 problems, and the IETF deprecated the 6to4 anycast relay mechanism. RFC 5158's old TLS dependency was also updated by the modern TLS requirements in RFC 8996. None of that is evidence that the described public service remains available today.

It would also be a mistake to dismiss the specification as irrelevant. Automated infrastructure still often derives permission from network position, validates a target's technical readiness, and installs state with an expiry timer. RFC 5158 shows exactly where that convenience stops: a bounded source-address capability is not durable administrative authority.

Sources

  1. RFC 5158, HTML
  2. RFC 5158, text
  3. RFC Editor record
  4. IETF Datatracker record
  5. RFC 5158 history
  6. RFC 5158 references
  7. RFC 5158 errata
  8. RFC 3056
  9. RFC 3068
  10. RFC 3964
  11. RFC 6343
  12. RFC 7526
  13. RFC 2136
  14. RFC 3596
  15. RFC 2317
  16. RFC 1034
  17. RFC 1035
  18. RFC 4033
  19. RFC 8996
  20. RFC 8446
  21. IANA IPv6 Special-Purpose Address Registry
  22. RFC 3172
  23. RFC 8020
  24. RFC 2308
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy