요약

  • RFC 2219는 사람과 프로그램을 서비스로 안내하는 데 널리 쓰이던 DNS 레이블들을 모아, 호스트가 바뀌더라도 안정적인 서비스 이름을 유지하기 쉽게 만들었다.
  • 이 문서는 또한 그 이름이 증명할 수 없는 것들을 정확히 밝혔다. 주소, 대기 중인 프로세스, 기대되는 포트, 클라이언트 서비스 의사, 또는 서비스를 찾는 완전한 방법은 아무것도 증명하지 않는다.

주소가 근거보다 더 확실해 보였다

브라우저에www.example.org를 입력하면 그 이름이 일종의 약속처럼 보인다. 실제로는 그렇지 않다. DNS 응답은 주소를 아예 반환하지 않을 수 있고, 주소는 HTTP 리스너가 없는 기계로 이어질 수 있으며, 리스너는 다른 포트를 사용할 수 있고, 정상 작동하는 서버조차 특정 요청을 거부할 수 있다. 1997년 10월, RFC 2219는 사람들이 이미 추측하는 데 익숙해진 레이블을 정리하려는 과정에서 이 간극을 명시적으로 드러냈다.

이 관례에는 분명한 매력이 있었다. 사람은 기계 이름을 알기 전에www,ftp,mail을 시도해 볼 수 있었다. 프로그램도 비슷한 추측을 할 수 있었다. 관리자 입장에서 더 중요한 점은, 익숙한 서비스 지향 이름이 나중에 주소나 하드웨어가 바뀌는 호스트를 가리키도록 할 수 있다는 것이었다. 방문자의 이름은 그와 함께 바뀔 필요가 없었다. RFC 2219는 이를 서비스를 기계 간에 투명하게 이동시키는 방법이자, 어떤 조직이 특정 서비스를 제공할 수 있다는 단서로 묘사했다.

이 문서는 새로운 DNS 레코드 유형이나 범용 서비스 디렉터리가 아니라 현재 최선의 실천(best current practice) 메모였다. 저자들은 별칭이 이미 일반적 관행이 되었다고 말하며, 그 ‘전승 지식(folklore)’을 일련의 기본값으로 모았다.www,ftp,gopher,ldap,mail,news,ntp,pop,whois같은 레이블이 그것이다. 목록에 없는 프로토콜의 경우, 프로토콜 사양이 이름을 제안하도록 기대되었다. 그 결과는 어휘의 표준화였을 뿐, 각 단어 뒤에 무엇이 대기하고 있는지 검증하는 거래가 아니었다.

이 구분은 부각주가 아니었다. RFC 2219는www라는 이름의 DNS 항목이 웹 서비스를 등록하는 것이 아니라고 경고했다. 그 이름은 주소로 해석될 필요가 없다. 어떤 호스트도 HTTP를 대기할 필요가 없고, 리스너가 포트 80을 사용할 필요도 없다. 이 조건들이 모두 충족되더라도, 서버는 임의의 클라이언트를 받아들일 필요가 없다. 저자들은 별칭을 유용한 ‘힌트(hints)’라고 부르며 구현자들이 그 정신으로 다루기를 요청했다. 레코드는 조직의 DNS 영역 안의 선언이었고, 서비스 동작은 다른 곳에 있었다.

이 힌트는 익숙한 형태가 시사하는 것보다 발견 과정의 뒤쪽에서 시작되었다. 먼저 조직의 도메인을 알아야 했다. RFC 2219는 프로그램이 기관 이름, 위치 또는 사업 분야에서 도메인을 추론하는 방법을 풀지 못했다. 또한 호스트 이름을 넘어 매개변수가 필요한 서비스도 다루지 못했다. 그 예가 LDAP인데, LDAP 클라이언트는 의미 있는 교환을 위해 검색 기저(search base)가 필요하다. 별칭은 이미 알려진 도메인에 접근하기 쉽게 만들 수는 있었지만, DNS를 범용 디렉터리로 바꾸지는 못했다.

이름을 옮기는 것은 유지보수 선택을 옮기는 것

RFC 2219는 서비스 지향 이름을 게시하는 두 가지 방법을 보여주었다. CNAME은ph.example.org를 정식 기계 이름의 별칭으로 만들 수 있었다. 이는 호스트가 이동할 때 주소 데이터를 반복할 필요를 줄여 주었지만, DNS 규칙상 CNAME 소유자 이름은 MX 같은 다른 레코드를 함께 가질 수 없었다. 대안은 서비스 이름 바로 아래에 하나 이상의 A 레코드를 게시하는 것이었다. 이렇게 하면 주소 데이터가 그 자리에 드러나지만, 그 값을 호스트의 다른 레코드와 조율해야 하는 부담이 따랐다. 이 RFC는 모든 사이트에 하나의 답을 강제하지 않았다. 올바른 배치는 현지 요구에 따라 달라졌다.

바로 이 지점에서 레이블의 편의성이 운영 부채로 변할 수 있었다. 별칭을 쓰는 경우 관리자는 대상을 최신으로 유지하고 대상이 사라지면 별칭을 제거해야 했다. 낡은 포인터는 여전히 포인터일 뿐, 상태 점검이 아니었다. 직접 주소를 쓰는 경우 모든 변경 시 서비스 지향 이름의 주소 집합을 실제로 서비스하는 기계들과 정합을 유지해야 했다. 여러 주소는 복제된 사이트를 지원할 수 있었고, 이 RFC는 클라이언트가 순서를 재배열하거나 자체 휴리스틱을 적용할 수 있음을 언급했다. 라운드 로빈 응답도 클라이언트 선택도 그 기계들이 정확한 복제본임을 보장하지 않았다. 문서는 그러한 배치가 기계들이 정확히 같은 경우에만 적절하다고 제시했다.

보안 경고도 같은 논리를 따랐다. DNS 데이터는 위조될 수 있다. 거짓 응답은 존재하지 않는 주소를 지목해 서비스 거부를 일으키거나, 클라이언트를 정상 서버로 위장하는 서버로 수동적으로 유도할 수 있다. 별칭 관례는 어떤 인증도 제공하지 않았다. 안심시키는 레이블이 곧 엔드포인트 점검이나 민감한 교환 보호를 대신할 수는 없었다.

RFC 2219는 자신의 접근이 범위 면에서 일시적이라는 것도 인정했다. 흔한 별칭은 특정 서비스를 찾는 문제에 대한 완전한 장기 해법이 아니며, 당시 RFC 2052였던 진행 중인 서버 위치 리소스 레코드(Server Location Resource Record) 작업을 그 노력의 하나로 지목했다. 이 연대기가 중요하다. SRV 제안은 RFC 2219 이전에 존재했고, RFC 2219는 이를 더 큰 발견 문제에 대한 별도의 대응으로 묘사했다. RFC 2782는 이후 RFC 2052를 대체하며 우선순위, 가중치, 포트, 대상을 갖춘 서비스·프로토콜 지향 레코드를 규정했다. 그 사용은 여전히 관련 애플리케이션 프로토콜이 클라이언트에 쿼리를 지시해야만 가능했다. 이후의 레코드가 소급적으로www를 서비스 등록 증명서로 바꾸지는 않았다.

RFC 2219가 보존한 것은 더 좁고 실용적이었다. 인식 가능한 이름은 운영자의 의도를 찾기 쉽게 하고 호스트 교체를 쉽게 할 수 있다. 그것이 보류한 것은 반대편 끝의 사실들에 대한 권한이었다. 영역(zone) 관리자는 힌트를 게시할 수 있었고, 호스트 운영자가 리스너를 통제했으며, 클라이언트는 여전히 접속해 응답을 판단해야 했다. 상징적인 정문은 옮겨질 수 있었다. 집 안에 사람이 있는지는 여전히 운영의 문제였다.

출처:RFC 2219;RFC Editor의 RFC 2219 기록;IETF Datatracker: BCP 17;RFC 1912;RFC 1034;RFC 1035;RFC 2052;RFC 2782;RFC 1123.