Summary

  • RFC 1183 proposed an RP record so a DNS name could identify a repair contact other than its zone administrator or the host's POSTMASTER. Its own example pointed a gateway toward a hotline outside the gateway's domain.
  • The record carried a mailbox name and a pointer to optional human-readable TXT information. Publishing either pointer identified a proposed contact route; it did not show that mail arrived or that anyone fixed the fault.

A gateway goes down. The DNS zone still has an administrator, and that administrator's address is still in the SOA record. Those are two comforting facts until somebody needs the gateway repaired. The person who maintains the zone database may have no idea what failed inside the gateway. The gateway itself may not receive mail. Sending to POSTMASTER can be just as useless. In October 1990, the authors of RFC 1183 described that mismatch without ceremony: for a gateway, the useful hotline might belong to another organization altogether.

Their answer was the Responsible Person resource record, or RP. It could sit at any DNS name, not only a zone's top-level label or a leaf host. An operator looking up the troublesome name could find a mailbox encoded as a DNS domain name. The RFC's example makes the politics of this little field plain. a gateway under ISI.EDU could point to a hotline at BBN.COM. DNS authority stayed with one institution; the practical call for help went to another. The record did not transfer control of the zone. It told a reader where to try when the machine needed attention.

The RP record had two required fields after its type code, 17. One named the mailbox. The other named a place to look for TXT records containing human-readable detail. Reusing that TXT name let several devices point to one contact description. A resolver needed a further lookup to fetch it; the record did not promise that the explanation would arrive bundled with the first answer. A bare root dot in the mailbox position meant no mailbox was available. A root dot in the TXT position meant there was no associated explanatory TXT record. Those are honest empty values, more useful than pretending every device has a reachable person.

The examples in the RFC are revealing because they are messy. Two hosts can point at the same descriptive TXT entry while naming different local mailboxes. One host can carry several RP records because several people might need to know when it fails. The text recommends identical TTLs for multiple RP records at one name. A person may be responsible for a service without being the DNS zone operator, and the same service may have more than one responsible person. That is an operating arrangement, not a tidy org chart.

The record also exposed a fresh duty. If an outside hotline changes hands, the RP mailbox and any shared TXT description must change with it. A perfectly answered DNS query can return a contact that left years ago. A published address establishes what the zone says; delivery, acknowledgement and repair require their own evidence. RFC 1183 was marked Experimental. It specified a way to express responsibility, not a count of deployed records or a history of resolved incidents.

This was an early, precise crack in the idea that the holder of a namespace can answer every question about what runs under it. The SOA contact could fix the zone file. POSTMASTER could handle mail. The person who could bring the gateway back might sit across an institutional border. RP put that border into a queryable record, where it could be found—and where neglect could also leave it stale.

Source: RFC 1183, New DNS RR Definitions, sections 2–2.2; RFC Editor record.