요약

  • RFC 1183은 특정 DNS 이름에 장비 장애 연락처를 붙일 수 있도록 RP 레코드를 제안했다. 연락처는 그 구역 관리자나 장비의 POSTMASTER와 달라도 됐다.
  • RP에는 메일함 이름과 사람이 읽을 TXT 설명을 찾을 이름이 들어갔다. 공개된 주소는 연락 경로일 뿐, 메시지 전달이나 대응, 복구의 증거는 아니었다.

게이트웨이가 멈췄는데 DNS는 답한다. SOA 레코드에는 구역 책임자의 주소도 있다. 얼핏 보면 연락할 사람을 찾은 셈이다. 그러나 구역 파일을 관리하는 사람이 게이트웨이 내부 고장을 수리할 줄 안다는 보장은 없다. POSTMASTER는 메일 문제를 다루며, 게이트웨이 자체가 메일을 받지 않을 수도 있다. 1990년 10월의 RFC 1183은 이 어긋남을 정면으로 짚었다.

제안한 레코드의 이름은 Responsible Person, RP. 유형 번호는 17이다. RFC의 예시는 조직 경계를 넘는다. ISI.EDU에 속한 게이트웨이가 BBN.COM의 지원 창구를 가리킬 수 있다는 것이다. 이름을 관리하는 기관은 그대로여도, 장애를 처리할 곳은 다른 기관일 수 있다. RP가 그 기관에 DNS 수정 권한을 주는 것은 아니다. 고장 소식을 어디로 보낼지 보여 준다.

레코드에는 두 개의 필수 데이터가 있었다. 첫째는 SOA 연락처와 같은 DNS 방식으로 적는 메일함이다. 둘째는 설명이 담긴 TXT 레코드를 찾을 이름이다. TXT를 읽으려면 별도 질의가 필요할 수 있다. 여러 장비가 한 설명을 공유하면 담당 부서 안내를 한곳에서 관리할 수 있다. 반대로 그 설명 하나가 낡으면 여러 장비의 연락 안내가 동시에 틀어진다.

루트 점 하나인 .은 메일함이 없거나 연결된 TXT가 없음을 나타낼 수 있다. 한 이름에 RP를 여러 개 붙이는 것도 가능하며, RFC는 이때 TTL을 같게 하라고 권한다. 예시에는 한 장비에 연락할 사람이 여러 명 나온다. 장비 운영, 메일, DNS 관리를 모두 한 사람의 책상에 밀어 넣지 않은 셈이다.

RP는 DNS 계층의 어느 노드에도 붙일 수 있어 실제 문제가 난 이름을 바로 조회할 수 있다. 하지만 외부 당직팀이 바뀌거나 메일함이 폐쇄됐는데 기록을 고치지 않으면, DNS는 오래된 연락처를 정확하게 돌려준다. RFC 1183은 Experimental 문서다. 연락처를 표현하는 방법을 정의했을 뿐, 얼마나 보급됐는지 또는 몇 건의 장애를 해결했는지 기록하지 않았다.

SOA 연락처는 구역 데이터를 고칠 수 있다. POSTMASTER는 메일을 다룬다. RP는 망가진 장비에 손을 댈 사람을 찾으려 했다. 이 세 목록을 맞춰 두는 담당자가 없다면, 새 레코드는 사람을 더 빨리 엉뚱한 곳으로 보내는 기계가 된다.

자료: RFC 1183, New DNS RR Definitions 2절~2.2절, RFC Editor 문서 정보.