Кратко

  • RFC 1183 предложил запись RP, чтобы у конкретного имени DNS можно было указать контакт по неисправности — в том числе в другой организации, отдельно от администратора зоны и POSTMASTER.
  • RP содержала почтовый адрес и ссылку на возможное пояснение в TXT. Ответ DNS показывал опубликованный маршрут обращения, а не факт доставки сообщения или ремонта.

Шлюз перестал работать. Его DNS-имя продолжает разрешаться, контакт в SOA на месте. Возникает соблазн считать вопрос с ответственным закрытым. Однако администратор зоны отвечает за базу имён и может не знать, кто обслуживает шлюз. POSTMASTER нужен для почтовых неполадок, да и сам шлюз может вовсе не принимать почту. С этого несовпадения начинается RFC 1183, опубликованный в октябре 1990 года.

Предложенная запись называлась Responsible Person, RP; ей присвоили код типа 17. Авторы привели пример с институциональной границей: шлюз в ISI.EDU мог указывать на линию помощи в BBN.COM. Управление DNS-зоной оставалось в одной организации, а полезный звонок уходил в другую. Запись не передавала оператору линии права изменять зону. Она давала ищущему ответ человеку конкретный следующий адрес.

Формат требовал два поля данных. Первое — почтовый ящик в принятой DNS-записи, такой же, как у контакта SOA. Второе — имя, по которому можно запросить TXT с пояснением для людей. Чтобы прочитать TXT, мог понадобиться отдельный запрос. Несколько машин могли ссылаться на один и тот же текст. Это экономило правки и одновременно делало устаревшую инструкцию общей проблемой для всех этих машин.

Корневая точка «.» могла обозначать отсутствие ящика либо отсутствие связанного TXT. У одного имени допускалось несколько RP; для них рекомендовалось одинаковое время жизни в кеше. В примерах на одну машину приходилось несколько адресатов. Порядок работы сети не обязан укладываться в один прямоугольник схемы управления: за устройство, почту и зону могут отвечать разные люди.

RP можно было разместить на любом узле дерева DNS, а не только у вершины зоны. Искомый контакт относился к тому имени, с которым возникла беда. Но смена дежурной команды, завершение договора или закрытие ящика быстро превращали правильный по синтаксису ответ в бесполезный. RFC 1183 получил статус Experimental. Документ задавал способ записи контакта, не приводя статистику внедрения и устранённых с его помощью аварий.

Контакт SOA ведёт к базе зоны. POSTMASTER ведёт к почте. RP пыталась вести к тем, кто может восстановить устройство. Если их списки не сверять, DNS просто начинает быстрее отправлять сообщения не туда.

Источник: RFC 1183, New DNS RR Definitions, разделы 2–2.2; карточка RFC Editor.