요약

  • RFC 1123는 숫자로 시작하는 인터넷 호스트명을 합법으로 만들었지만, RFC 1178은 기존 소프트웨어가 이를 수치 주소로 오인할 수 있으므로 그러한 선택을 여전히 피하도록 권고했다.
  • RFC 1178에게 이름은 임의의 꼬리표였다. 사람, 프로젝트, 장소, 역할을 꼬리표에 넣으면 기계나 조직이 움직인 뒤에는 의미만 낡아간다.
  • 유효한 label은, 애플리케이션이 선택한 해석 경로, 짧은 이름을 보완한 도메인, DNS 응답, 응답 주체의 동일성, 이름 변경 이후의 의존성 이전을 증명하지 못했다.

규격의 허용과 운용상의 선택

RFC 1178은 1990년 8월에 FYI 5로 발행되었다. 이전 수필을 다시 실은 정보 문서이며, 표준이 아니다.RFC Editor 기록과IETF Datatracker는 발행 사실과 상태를 보여주지만, 본문의 일화를 독립된 장애 보고로 만들지는 않는다.

RFC 1123은 별개의 역할을 맡았다. 제2.1절은 기존 제한을 완화하여 호스트명의 첫 글자를 영문자 또는 숫자로 하고, 호스트 소프트웨어에 이를 지원하도록 요구했다.RFC Editor 정보는 Host Requirements로서의 위치를 보여준다.

그럼에도 RFC 1178은 숫자로 시작하지 않도록 권고했다. 같은 입력란에서 이름과 수치 인터넷 주소를 함께 받는 프로그램 가운데는 양자를 올바르게 구분하지 못하는 것이 있었다. 16진수 숫자만으로 이루어진 단어에도 비슷한 위험이 있었다. 규격은 구현이 도달해야 할 조건을 보여주고, 명명 지침은 갱신 속도가 다른 구현 집단에서 모호성을 줄인 것이다.

따라서 "구문상 유효"라는 사실은 DNS가 호출된 증거가 아니다. 애플리케이션이 그 전에 주소로 판정했을 가능성을 실행 기록으로 확인해야 한다.

이름은 기계의 이력서가 아니었다

RFC 1178은 이름을 임의의 tag로 본다. 처음의 프로젝트 이름을 기계에 붙이면, 두 번째 기계가 합류하고, 일이 나뉘고, 원래의 기계가 다른 부서로 옮겨갈 때 꼬리표는 거짓말을 하게 된다. 끝의2나3은 구별에는 되지만 지속하는 의미에는 되지 못한다.

사람 이름을 쓰면 대화에서 사람과 기계가 섞인다. 소유자나 하드웨어가 바뀌어도 같은 꼬리표를 재사용하면, 옛 기계의 주변 기기나 데이터베이스를 전제로 한 프로그램이 새로운 대상에 낡은 기대를 가져온다.

호스트명이 보여줄 수 있는 것은, 어떤 label이 설정 또는 공개되었다는 사실까지다. 현재의 용도, 관리자, 장치, 서비스, 소유권, 시간적 연속성은 별개의 대장과 관측을 필요로 한다.

DNS 앞에 입력 분류가 있었다

RFC 1123은 이용자가 호스트의 도메인명 또는 점으로 구분된 10진수 IP 주소를 입력할 수 있도록 권고했다. 수치 형식을 먼저 구문 판정하고, 그다음에 DNS를 찾는다. 이름 해석의 손앞에 분기가 놓여 있었다.

구(舊)RFC 952의 DoD host table은 영문자로 시작할 것을 요구했다. 그RFC Editor 기록에는 RFC 1123에 의한 갱신 관계가 있다. 규칙이 바뀐 날과, 모든 프로그램과 script가 옛 전제를 버린 날은 일치하지 않는다.

조사에서는 입력 문자열, 애플리케이션과 버전, 이름/주소 분기, 생성된 query, RR type, resolver 설정, cache, 응답, 선택된 주소, 접속을 순서대로 남겨야 한다. 합법성은 이 첫 번째에만 답한다.

짧은 이름은 로컬 환경에서 의미를 빌렸다

RFC 1034는 절대 이름과 상대 이름을 나눈다. 상대 이름은 local origin이나 search list에 의해 보완되며, 사용자 인터페이스에서의 해석은 구현마다 달라질 수 있다.RFC Editor 정보는 특정 단말의 검색 순서를 증명하지 않는다.

RFC 1178은 한 단어짜리 메일 수신처에서 이 차이를 보였다. 어느 mailer는 local domain을 더하고, 다른 구현은 다른 domain의 이름으로 다룬다. 화면 위의 문자가 같아도, 실질적인 수신처는 문맥에 따라 바뀐다.

같은 label은 다른 부모 아래에서 재사용할 수 있다. DNS가 금지하는 것은 같은 부모 아래의 sibling 중복이지, 나무 전체의 중복이 아니다. 짧은 이름은 global identity가 아니다. FQDN조차 typed resource data의 node를 가리킬 뿐이며, 응답한 기계나 service를 인증하지 않는다.

사람이 쓸 수 있다는 것도 신뢰성의 일부였다

짧음, 보통의 철자, case, 명명 theme에 대한 조언은 DNS의 새로운 길이 제한이 아니다. 전화로 전하는, 장애 시에 입력하는, alarm에서 찾는, 명명자 이외의 사람이 읽는다는 운용 비용을 다룬다. 기묘한 철자는 올바르더라도 복구를 늦춘다. 대소문자는 별개의 동일성을 만들지 않는다. 유한한 theme은 기계 증설로 다 써버린다.

이름은 대화, ticket, command, mail, log, 화면, backup label을 건너다닌다. 그때마다 의미가 흔들릴 수 있으므로, 구문 적합만으로는 품질 판정이 되지 않는다.

이름 변경은 숨은 참조를 찾는 작업이었다

RFC 1178은, 눈에 띄지 않는 소프트웨어, 외부의 통신 상대, 오래된 backup media의 꼬리표에 옛 이름이 남을 수 있다고 경고한다. authoritative record를 바꾸어도, 그 사본들은 다시 쓰이지 않는다.

RFC 952는 일반적인 nickname을 권하지 않았지만, 이름 변경의 이행 중에는 옛 이름과 새 이름의 병존을 인정했다. alias는 계속을 도울 수 있어도, 이행 완료를 증명하지 않는다.

완전한 증거에는, 결정권자, 공개 시각, 호환 기간, cache 만료, code, 인증서, access control, monitoring, 문서, 외부 이용자의 이전, 옛 이름 이용의 감소, 예외 소유자, 종료 조건이 필요하다. 이는 RFC 1178의 축자적 절차가 아니라, 같은 문서가 보여준 의존의 귀결이다.

출처