IANA는 이름에 ‘특별’ 도장을 찍었다. 리졸버는 답을 골라야 했다.

요약

• 2013년 2월의 RFC 6761은 IANA 특별 사용 도메인 이름 등록부를 만들었다. 새 이름을 넣으려면 사용자부터 등록기관까지 일곱 부류가 그 이름을 어떻게 취급할지 명시해야 한다.
• 첫 목록에는 예전부터 예약된 이름과 사설 주소의 역방향 조회 구역이 함께 들어갔다. 같은 표의 항목이어도 localhost는 루프백, invalid는 즉각적인 부정 응답, 사설 역방향 구역은 현지 네트워크의 처리가 핵심이다.
• 2017년 RFC 8244은 IETF와 ICANN 사이에 특별 사용 이름을 위한 공식 조정 절차가 없고 ‘기술적 사용’의 범위도 합의되지 않았다고 적었다. IANA의 행은 지정 사실을 보여 주지만, 실제 리졸버의 응답은 실행 기록으로 확인해야 한다.

등록표는 DNS 질문에 답하지 않는다

개발자가 시험용 이름을 프로그램에 넣는다. 앱은 이름 해석 라이브러리를 부르고, 라이브러리는 캐시 DNS 서버에 질의할 수 있다. 서버는 다시 권한 서버를 찾을 수 있다. 다른 곳에서는 등록기관이 그 이름을 팔 수 있는지 결정한다. 글자는 하나인데 결정을 내리는 곳은 여러 군데다. IANA가 한 칸에 ‘특별’이라고 쓴 순간 모든 장치가 같은 동작을 시작하지는 않는다.

1999년의 RFC 2606은 시험, 문서의 예시, 실패가 예정된 이름, 로컬 호스트를 위해 몇몇 이름을 예약했다. 가짜 예시가 나중에 실제 도메인과 부딪히는 문제를 다뤘다. RFC 6761은 2013년에 다음 단계로 갔다. 이미 예약한 이름을 누가 알아보고, 어느 지점에서 질의를 멈추며, 어떤 응답을 돌려줄 것인가? 판매 금지는 등록 절차의 일이고, 올바른 응답은 실행 중인 소프트웨어의 일이다.

새 IANA 등록부는 기존 예약 이름과 사설 주소 역방향 구역으로 출발했다. 항목마다 동작을 정의하는 문서를 가리킨다. 이 표는 규칙으로 가는 색인이지, 질의가 날아갈 때마다 들르는 중앙 서버가 아니다. 따라서 목록에 있다는 사실과 한 사용자의 기계에서 벌어진 일은 서로 다른 증거다.

하나의 이름 앞에 놓인 일곱 질문

RFC 6761에 따르면 새 특별 사용 이름은 IETF의 Standards Action이나 IESG 승인을 받은 명세로 정의해야 한다. 대상 이름을 분명히 하고 일곱 부류에 대한 예약 고려사항을 적는다. 사람이 특별함을 알아봐야 하는가? 앱은? 이름 해석 API와 라이브러리는? 캐시 DNS 서버와 권한 서버는? 운영자는 무엇을 알아야 하는가? 레지스트리와 등록기관은 신청을 어떻게 처리해야 하는가?

이 질문은 같은 명령을 일곱 번 반복하지 않는다. 예를 들어 10.in-addr.arpa 같은 사설 주소 역방향 구역에서는 앱과 이름 해석 API가 설정된 캐시 서버에 보통 방식으로 질의해야 한다. 캐시 서버는 기본적으로 외부 권한 서버까지 따라가지 않고 현지에서 답해야 한다. 사설 네트워크가 별도 권한 서버를 운영하면 그쪽을 이용할 설정도 가능하다. 앱에서 DNS 패킷이 나갔다고 해서 설계가 어긋난 것이 아니다. 결정권이 그 다음 단계에 놓여 있다.

localhost의 주소 질의는 다르다. API와 캐시 서버가 루프백 주소를 돌려줘 공개 DNS로 떠돌지 않게 해야 한다. invalid는 빠른 NXDOMAIN 응답이 맞다. ‘예약’이라는 같은 말 안에 서로 다른 응답과 책임 지점이 들어 있다. 공개 리졸버 하나를 시험해도 앱의 라이브러리가 먼저 답했는지는 알 수 없다. 등록부를 열어 봐도 어느 구성 파일이 작동했는지는 보이지 않는다.

현재 IANA 목록에는 localhost, invalid, local, onion, home.arpa, 사설 역방향 구역 등이 각자의 참조 문서와 함께 실려 있다. 어떤 항목은 DNS 안에서 특별하게 처리되고, 어떤 항목은 로컬 해석이나 앱의 맥락이 중요하다. RFC 6761은 이를 최상위 도메인으로만 제한하지 않았고 모든 이름이 DNS를 우회해야 한다고도 정하지 않았다. 하나의 분류가 하나의 처리 경로를 뜻하지 않는다.

이름은 이동하지만 맥락은 남는다

한 사람이 내부에서 쓰는 이름을 메시지에 복사한다. 다른 네트워크의 받는 사람은 똑같은 글자를 입력한다. 이름은 이동했지만 의미를 주던 환경은 따라오지 않았다. 다른 대상으로 이어지거나 아무 데도 닿지 않을 수 있다. RFC 8244은 세계 어디서나 통할 것처럼 보이는 이름과 현지에서만 성립하는 의미가 충돌하는 문제를 다뤘다.

2017년 10월 문서는 해결책을 확정한 규칙이 아니라 문제 목록이었다. IETF와 ICANN은 연락 관계를 갖고 있었지만 특별 사용 이름의 할당을 공식적으로 조정하는 절차는 없었다. ‘기술적 사용’이 어디까지인지도 합의되지 않았다. 두 기구 모두 이름 공간에 역할이 있었으나, 외부 개발자가 허가 없이 어떤 문자열을 먼저 사용하는 일까지 막을 수는 없었다.

목록에는 현장에서 벌어질 수 있는 일도 들어 있다. 내부 이름이 밖으로 새고, 비공식 사용이 훗날의 공식 할당과 충돌한다. 개발자가 절차를 모르거나 신청이 거절될 것으로 예상할 수도 있다. 특정 제품에서 어떤 일이 일어났는지 말하려면 당시 설정과 질의 기록이 필요하다. 등록부는 지정 날짜를 알려 주지만, 한 기계의 응답을 재생해 주지는 않는다.

이 사건의 마른 농담은 분명하다. 기관은 특별한 이름을 넣을 반듯한 서랍을 만들었다. 서랍 속 카드 한 장은 서로 주인이 다른 일곱 작업대로 연결됐다. 2013년의 질문은 새 카드를 넣기 전에 각 작업대의 일을 쓰게 했다. 2017년의 문서는 서랍을 여는 절차마저 조정할 일이 남아 있음을 드러냈다.