DNS의 밑줄 이름에 문지기가 생긴 이유

요약

• 2019년 3월의 RFC 8552는 부모 도메인에 관한 레코드를 밑줄 이름 아래의 가지에 놓는 관행을 정리했다. DNS 루트에 가장 가까운 밑줄 이름이 전역 범위를 갖는다.
• IANA 등록부는 레코드 종류와 전역 밑줄 이름의 조합을 관리한다. 전문가 검토는 그 조합의 명확성과 고유성을 살피며, 더 아래의 이름은 해당 프로토콜의 규칙을 따른다.
• RFC 8553은 과거 명세와 SRV·URI 틀을 통합 등록부에 맞춰 고쳤다. 기존 소프트웨어와 운영은 유지했다. 등록부의 한 줄은 이름 배정의 증거이며, 특정 도메인의 실제 게시 내용은 권한 DNS 응답에서 확인해야 한다.

레코드 종류만으로는 뜻이 모자랐다

DNS에는 이름과 레코드 종류가 있다. 기본 규칙은 도메인 이름의 각 조각에 보편적인 뜻을 주지 않고, 특정 레코드 종류가 들어갈 수 있는 자리도 하나로 묶지 않는다. 이 자유 덕분에 응용 프로그램은 새 DNS 종류 번호를 매번 만들지 않고 기존 종류를 재사용할 수 있었다. 하지만 재사용이 늘면 같은 종류의 값들이 서로 다른 지시를 담게 된다.

TXT가 쉬운 예다. 두 프로그램이 한 도메인에 관한 TXT를 게시하더라도, 각각이 읽어야 할 자료는 전혀 다를 수 있다. 두 프로그램이 모두 부모 도메인 바로 아래에 놓으면, 클라이언트는 받은 뒤에 값들을 다시 골라야 한다. RFC 8552가 설명한 방식은 위치를 먼저 나누는 것이다. _name.example.org 같은 가지 아래에 해당 프로토콜의 레코드를 놓고, example.org는 그 정보가 설명하는 부모 도메인으로 남긴다.

밑줄은 호스트 이름과 이 자리를 구분한다. _name은 name이라는 새 서버를 만들겠다는 표시가 아니라, 부모 도메인의 속성을 담을 별도 주소다. DNS 패킷이나 TXT의 형식은 바뀌지 않는다. 레코드를 찾는 이름이 그 레코드의 해석 범위를 좁힌다. 프로토콜 하나만 보면 깔끔한 작명법이다. 여러 프로토콜이 같은 공간에서 새 이름을 고르면 배정 규칙이 필요해진다.

이 관행은 2019년에 갑자기 태어나지 않았다. 2000년 2월의 RFC 2782는 SRV에 _Service._Proto.Name 형식을 쓰고 서비스와 프로토콜 이름 앞에 밑줄을 붙여 일반 호스트 이름과의 충돌을 피했다. DNS-Based Service Discovery도 나중에 이 관행을 썼다. 그 문서들은 각자의 서비스 조회를 다룬다. RFC 8552의 관심사는 조회 결과에서 서버를 고르는 일이 아니라, 서로 다른 문서가 공통 이름 자리를 어떻게 차지하는가였다.

공통 자리는 루트 가까이에 있다

한 가지 안에는 밑줄 이름이 여럿 있을 수 있다. RFC 8552가 전역 이름이라고 부르는 것은 DNS 루트에 가장 가까운 밑줄 이름이다. 그 아래의 이름은 전역 가지를 맡은 프로토콜이 정의한다. 사람이 이름을 왼쪽부터 읽으며 먼저 만난 밑줄을 전역 이름으로 착각하면 배정 주체를 잘못 찾게 된다. 이름의 문자 순서보다 DNS 나무에서의 위치가 중요하다.

IANA의 ‘Underscored and Globally Scoped DNS Node Names’ 등록부에는 RR 종류, 밑줄 노드 이름, 참조 문서가 실린다. 열쇠는 (RR Type, _NODE NAME)이라는 쌍이다. 한 종류의 레코드는 서로 다른 전역 이름 아래 쓰일 수 있다. 한 전역 이름도 레코드 종류가 다르면 별개의 항목이 될 수 있다. 문제는 같은 쌍을 다시 배정해 다른 뜻을 주장하는 경우다. 이때 클라이언트가 정확한 DNS 주소에 물어도 서로 다른 프로토콜의 기대가 부딪힌다.

등록 방식은 전문가 검토다. RFC 8552는 이름과 종류의 쌍이 고유하고 설명이 분명한지 보도록 한다. 프로토콜 전반의 기술적 품질을 판정하는 절차는 아니다. 등록된 주소가 있다는 사실은 해당 응용 프로그램이 잘 설계됐다는 인증이 아니다. 어느 도메인 운영자가 그 가지에 자료를 넣었다는 증거도 아니다. 등록부가 해결하는 문제는 이름의 이중 배정이다.

그래서 자료를 읽는 순서가 세 단계로 나뉜다. IANA 항목에서 전역 자리를 확인한다. 거기에 연결된 명세에서 하위 이름과 사용법을 읽는다. 특정 도메인의 권한 DNS 응답에서 그 도메인이 실제로 낸 레코드를 본다. 첫 단계의 표가 세 번째 단계의 운영 기록을 대신할 수 없다.

오래된 문서를 나중에 묶었다

통합 등록부보다 밑줄 이름을 쓴 문서가 먼저 나왔다. 새 표가 생기기 전의 RFC들은 자신들의 이름을 각각 정했다. RFC 8552와 함께 2019년 3월에 나온 RFC 8553은 그 문서들을 정리했다. 기존 규격의 참조를 고치고 SRV와 URI의 새 이름을 정의할 때 쓰는 틀도 하나의 등록 절차를 가리키게 했다.

문서를 고쳤다고 네트워크가 하룻밤에 이름을 갈아 끼운 것은 아니다. RFC 8553은 기존 소프트웨어와 운영 관행을 보존한다고 명시한다. 와이어 형식은 그대로다. 달라진 것은 앞으로 전역 밑줄 이름을 요청하는 절차와 오래된 문서의 배정 근거를 찾는 방법이다. 이미 돌아가는 구성을 새 표에 맞추려고 깨뜨렸다면 조정의 비용이 충돌의 비용보다 커졌을 것이다.

이 사연은 지역적으로 훌륭한 규칙이 전역적으로도 충분하리라는 착각을 찌른다. 각 프로토콜은 자신의 하위 가지를 정교하게 설계할 수 있다. 두 프로토콜이 바깥쪽 같은 이름과 같은 종류를 골랐다면 그 정교함만으로 충돌을 막을 수 없다. 2019년의 답은 DNS 나무 전체를 중앙에서 설계하는 것이 아니었다. 독립된 설계가 만나는 가장 작은 경계에만 공동 장부를 둔 것이다.

공식 문서로 확인되는 사실은 이름 규칙, 등록 쌍, 과거 명세의 수정이다. 특정 서비스가 실제로 이 방식을 배포했다는 주장을 하려면 날짜가 확인되는 권한 영역 자료와 그 이름을 조회한 클라이언트 기록이 더 필요하다. 배정과 사용은 다른 사건이다.