요약

  • ENUM은 E.164 번호를 DNS 키로 변환하고 NAPTR 규칙을 처리하여 URI를 생성합니다. 그 결과는 가능한 서비스 접점을 식별할 뿐, 완성된 통신 세션은 아닙니다.
  • 방어 가능한 통화 기록은 번호 소유권 검증, DNSSEC 상태, 선택된 NAPTR, 생성된 URI, 다운스트림 피어 인증, 시그널링, 관찰된 양방향 미디어를 결합하되, 이를 “ENUM 성공”으로 압축하지 않아야 합니다.

통신 콘솔이 E.164 번호를 받아 성공을 보고했다. 입력은 정규화되었고, 자릿수는 역순으로 배열되어e164.arpa이름이 되었으며, NAPTR RRSet이 유효한 DNSSEC과 함께 도착했고, 클라이언트는 SIP URI를 생성했다. 그러나 다음 조회에서는 낡은 서비스 대상이 나왔다. 아니면 피어가 초대를 거절했다. 아니면 아무도 응답하지 않았다. 아니면 시그널링은 완료되었지만 미디어는 한 방향으로만 흘렀다.

이 과정 어느 단계도 ENUM 결과를 거짓으로 만들지 않는다. 오류는 콘솔에 붙은 라벨에 있다. URI 이후의 모든 전환을 삭제함으로써 “조회됨”이 “연결됨”으로 승격된 것이다.

Patrik Fältström과 Michael Mealling은 ENUM에 대한 2004년 Standards Track 사양인RFC 3761을 저술했다. 이 문서는 이후 Scott Bradner, Lawrence Conroy, Kazunori Fujiwara가 집필한RFC 6116에 의해 폐기(obsoleted)되었다. 후속 RFC는 스스로를 Fältström과 Mealling이 편집한 문서의 업데이트라고 명시한다. 이 계보는 중요하다. ENUM은 한 개인의 소유물이나 운영 결정이 아니라 집단적이고 개정되는 표준 작업이다.

이 아키텍처의 지속적인 기여는 좁으면서 강력하다. 응용 프로그램이 전화번호에서 시작하여 DNS를 통해 URI를 발견할 수 있게 한다. DNS를 전화 교환기, 번호 할당 기관 또는 사람 대화의 목격자로 만들지는 않는다.

번호가 DNS 키가 되는 과정

RFC 6116은 먼저 Application Unique String을 정의한다. 클라이언트는 완전한 E.164 번호에서 표시용 구두점을 제거하되 선행 플러스 기호는 유지한다. 그다음 잘 알려진 첫 규칙이 플러스 기호를 제거하고 자릿수를 뒤집어 점으로 구분한 뒤.e164.arpa.를 붙인다. 익숙한 번호가 정확한 DNS 이름이 된다.

이 변환이 증명하는 것은 소박하다. 클라이언트가 이 DDDS 응용에 대해 규정된 키를 구성했다는 사실이다. 현재 그 번호를 사용할 권리를 가진 사람이 누구인지는 증명하지 않는다. 입력이 승인된 발신자에게서 왔는지, 등록기관이 번호 이동성(portability)을 따라갔는지, 응용 프로그램이 그 이름 아래 공개된 모든 서비스에 접속해야 하는지도 증명하지 않는다.

DNS 질의는 NAPTR 레코드를 검색한다. 터미널 레코드는 최종 출력을 만들 수 있고, 비터미널 레코드는 다른 도메인 이름과 다음 처리 라운드를 만든다. 마지막 DDDS 루프의 기대 출력은 절대 URI이다. 따라서 ENUM의 끝점은 주소 표현식이지 통화 상태 이벤트가 아니다.

RFC 3403은 규칙 기계를 명시적으로 정의한다.ORDER는 어느 규칙 그룹을 먼저 고려할지 결정한다. 그룹 내에서PREFERENCE는 그 밖에 자격이 있는 레코드 사이의 선택을 돕는다.FLAGS,SERVICES,REGEXP,REPLACEMENT는 응용 프로그램이 값을 해석하거나 재작성하는 방법을 알려준다. URI만 캡처하면 그 URI가 왜 선택되었는지가 사라진다.

하나의 규칙이 반환되어도 선택은 남는다

RFC 6116은 ENUM 알고리즘이 항상 단일 규칙을 반환한다고 말한다. 이 문장은 실행 판정처럼 들릴 수 있다. 그렇지 않다. 응용 프로그램은 자체 지식을 가질 수 있고, 사용자에게 여러 가능한 URL을 보여줄 수 있으며, 일부 Enumservice만 지원하거나, 형식이 잘못되었거나 비공개인 레코드를 폐기하거나, 동일한 정렬 값을 가진 접점 사이에서 선택할 수 있다. RFC는 클라이언트가 RRSet을ORDER와PREFERENCE순으로 정렬하도록 요구하지만, DNS 전송 순서는 신뢰할 수 있는 동순위 결정자가 아니라고 경고한다.

등록자의 선호도도 명령에는 못 미친다. RFC 6116은 등록자가 지원할 의향이 있는 접점만 공개하라고 조언하는데, 가장 매력적이지 않은 정렬 값을 가진 접점조차 최종 사용자가 선택할 수 있기 때문이다. 이는 가능한 클라이언트 행동에 대한 진술이다. 그 접점이 지금 활성 상태인지, 응용 프로그램이 그 스킴을 구현하는지, 다운스트림 제공자가 요청을 수락하는지 보장하지 않는다.

그렇기 때문에 운영 추적에는 후보 전체 집합이 필요하다. 반환된 모든 NAPTR, 그 TTL, order, preference, 서비스, 플래그, 재작성 값을 기록하고, 클라이언트가 지원하는 서비스와 각 레코드가 유지되거나 폐기된 이유를 기록하라. 그 분모 없는 최종 URI는 클라이언트가 정책을 따랐는지, 동순위에 직면했는지, 낡은 데이터를 사용했는지, 호환 가능한 대안이 없었는지를 설명할 수 없다.

번호 소유권은 상류의 영수증이다

ENUM 이름은 일반적인 선착순 레이블이 아니다. E.164 할당과 결합되어 있다.RFC 4725가 검증 아키텍처를 설명하는 이유는 정확히 DNS 트리가 별도의 번호 체계를 추적해야 하기 때문이다.

이 문서는 번호 할당 주체, 번호 사용 권리를 가진 피할당자(assignee), ENUM 등록자, 검증 주체, 레지스트리, 등록기관, DNS 서비스 제공자, 응용 서비스 제공자를 구분한다. 검증 주체는 등록자가 피할당자이거나 그를 대행하도록 승인되었는지 확인한다. 문서는 또한 조건이 무효화될 때 위임을 취소할 방법을 요구한다. 최초 검증 뒤에는 반복 검증 또는 재검증이 이어진다.

이것들은 프로비저닝과 거버넌스 사실이다. 모든 NAPTR 응답 안에 자동으로 실려 이동하지 않는다. 레코드를 받은 리졸버는 DNS 데이터를 검증할 수 있지만, 그 위임 뒤에 있는 현재의 검증 거래, 번호 이동 상태 또는 로컬 정책 결정은 알지 못할 수 있다. “이름이 존재했다”와 “등록자가 그 시점에 여전히 번호를 통제했다”는 서로 다른 증거를 요구한다.

이 구분은 양쪽을 모두 보호한다. 낡은 레코드는 사기의 증거가 아니다. 캐시 수명, 동기화되지 않은 갱신 또는 지연된 취소가 설명이 될 수 있다. 유효한 과거 토큰도 현재의 통제를 증명하지 못한다. 유용한 감사 조인에는 할당 버전, 검증 방법, 검증 시각, 만료 또는 재검증 상태, 위임 변경, 클라이언트가 관찰한 정확한 DNS 데이터가 포함된다.

DNSSEC는 데이터를 인증하지 서비스 피어를 인증하지 않는다

RFC 6116의 보안 절은 이 경계를 보기 드물게 직설적으로 진술한다. DNSSEC는 DNS 데이터의 진위를 검증하고 ENUM에 대한 많은 공격을 완화할 수 있다. 서비스를 모든 공격에 면역으로 만들지는 못한다. 특히 DNSSEC로 검증된 ENUM 조회를 통해 주소를 얻는다고 해서, 그 주소에 도달한 주체가 사용자가 의도한 서비스 피어라는 보장은 없다.

그래서 RFC는 서비스가 발견 단계 밖에서 얻은 주소나 신원 데이터에 의존하기보다 서비스 설정 과정에서 피어를 인증하라고 지시한다. 이는 설계 끝자락에 묻힌 단서 조항이 아니라 발견과 통신 사이의 인계점이다.

캐싱은 이 인계를 길게 늘린다. RFC 6116의 SIP 예제는 ENUM URI로 시작해, 사용자 에이전트가 세션 시작을 시도하기도 전에 SIP 도메인에 대한 추가 NAPTR 처리, 서버에 대한 SRV 조회, 호스트에 대한 주소 조회를 수행한다. 이 레코드들은 서로 다른 TTL을 가질 수 있고 서로 다른 존에서 변경될 수 있다. 완벽하게 진위가 확인된 레코드 모음조차 시간적으로 일관되지 않을 수 있다.

DNSSEC 상태는 유지하되, 초록 방패가 영수증의 나머지를 대신하도록 두지 말라. 검증 체인, 시작과 만료 시각, 부(negative) 응답, 리졸버 신원, 캐시 연령, 모든 다운스트림 조회를 보존하라. 그런 다음 실제 서비스 피어를 인증하고 시그널링 시도를 그 신원에 결합하라.

음성 URI는 또 다른 프로토콜을 시작한다

RFC 4415는voice:telEnumservice를 등록했다. 그 문구는 정확하다. 생성된 URI에 담긴 접점은 상호작용 음성 통화를 개시하는 데 사용될 수 있다. 다이얼러는 URI의 전화번호를 사용해 PSTN 또는 PLMN 연결을 통해, 직접 혹은 IP 제공자와 게이트웨이를 거쳐 통화를 건다.

“개시할 수 있다”는 능력 경계이다. 클라이언트는 해당 타입과 서브타입을 지원해야 한다. 제공자는 요청을 인증하고 승인할 수 있다. 라우팅은 목적지를 찾거나 실패할 수 있다. 상대 엔드포인트는 울리거나, 거절하거나, 전환하거나, 시간 초과되거나, 응답할 수 있다. 그 후 미디어는 자체의 협상된 경로를 필요로 한다. 이 사건들 중 어느 것도 이전 NAPTR 결과에 인코딩되지 않는다.

SIP URI가 이 분리를 보여준다.RFC 3261은 잠재 참가자를 찾고 세션을 생성·수정·종료하기 위한 별개의 프로토콜을 정의한다. SIP에는 트랜잭션, 인증과 승인, 초대, 잠정 및 최종 응답, 확인(acknowledgement), 다이얼로그 상태가 있다. ENUM은 입력 URI를 제공할 뿐, 그 상태 기계를 미리 실행하지 않는다.

운영 질문에 대해 “SIP가 성공했다”조차 너무 넓을 수 있다. 수락된 초대만으로는 양방향 오디오가 의도된 경로를 통과했는지, 사람 간 대화가 발생했는지, 얼마나 지속되었는지, 과금이 정책과 일치했는지 보여주지 않는다. 이 주장들은 프라이버시와 보존 규칙으로 경계된 미디어 관찰과 응용 기록을 필요로 한다.

통화 영수증을 순서대로 만들어라

유용한 영수증은 원래 번호와 정규화 규칙에서 시작한다. 다음은 도출된 DNS 키, 리졸버, 질의 시각, DNSSEC 검증, 전체 NAPTR RRSet, TTL, 비터미널 재작성 체인이다. 클라이언트는 지원하는 Enumservice, 후보 집합, 선택 근거, 최종 URI를 기록한다.

후반부는 또 다른 제어 평면에 속한다. 다운스트림 DNS 해석, 인증된 피어, 제공자 승인, 시그널링 요청, 트랜잭션 식별자, 응답, 확인, 종료 사유. 그 뒤에야 기록은 기대된 미디어 엔드포인트가 양방향 패킷을 주고받았는지, 응용이 세션을 사용 가능하다고 판단했는지, 관찰이 얼마나 유효하게 유지되었는지 진술할 수 있다.

각 요소는 성공하면서 다음이 실패할 수 있다. 이는 관료적 중복이 아니다. 시스템이 만료된 번호 위임과 낡은 캐시를, 지원되지 않는 Enumservice와 도달 불가능한 호스트를, 잘못된 서비스 피어와 거절된 발신자를, 수락된 시그널링과 한 방향 오디오를 구분하는 방식이다.

출처