요약

  • DNS WKS는 하나의 IPv4 주소, 하나의 IP 프로토콜, 그리고 조밀한 포트 비트맵을 담았습니다. 비트가 설정되어 있으면 해당 서비스가 대기 중이어야 함을 말해 주지만, 레코드가 준비된 시점에 영역 게시자가 참이라고 의도한 내용만 보고할 수 있었습니다.
  • 메일 라우팅은 잠시 이 비트맵을 연결 전 근거로 취급했습니다. RFC 974는 SMTP 비트가 없는 MX 후보를 폐기하도록 메일러를 권장했고, RFC 1123은 스파스한 사용 때문에 비트 부재가 신뢰할 수 없어졌다며 이 권고를 뒤집었습니다.
  • 이 교정은 기술적이기 이전에 인식론적이었습니다. 포트 할당, DNS 게시, 네트워크 허가, 살아 있는 프로세스 상태, 애플리케이션 신원은 서로 다른 주장이며, 후자의 조건은 실제 시도만이 확인할 수 있습니다.

첫 패킷 이전의 비트 25

1986년의 메일 전송 에이전트가 MX 대상을 검토하는 장면을 상상해 보십시오. 아직 TCP SYN을 보내지 않았고 SMTP 인사말도 받지 못했습니다. 대신 DNS에 Well Known Service 레코드를 조회하고 프로토콜 6, 즉 TCP에 대한 비트맵을 읽습니다. 26번째 비트—0부터 셉니다—가 설정되어 있습니다. 그 위치는 포트 25에 해당합니다. 메일러는 SMTP 서버가 대기 중이어야 한다고 믿도록 초대받는 셈입니다.

이 유혹의 이유는 쉽게 이해됩니다. 실패한 연결에는 시간이 듭니다. 메일 익스체인저는 여러 대상을 게시할 수 있습니다. DNS가 호스트의 위치와 익숙한 서비스 목록을 동시에 말해 준다면, 클라이언트는 실제로 접촉하기 전에 불가능한 후보를 제거할 수 있습니다. 컴팩트한 목록이 불확실성을 한 번의 조회로 해소해 주는 것처럼 보입니다.

와이어 형식은 이 목록을 유난히 결정적인 것처럼 보이게 만들었습니다.RFC 883이 1983년 11월에 WKS를 정의했습니다.RFC 1035는 4년 뒤에도 이를 유지했습니다: 32비트 인터넷 주소, 8비트 IP 프로토콜 번호, 그 뒤를 잇는 가변 길이 비트맵. 비트 0은 포트 0, 비트 1은 포트 1을 뜻합니다. 전송된 끝을 넘어선 비트는 0으로 간주됩니다.

TCP 포트 25에 대해 RFC 1035는 설정된 비트가 SMTP 서버가 대기 중이어야 함을, 0은 그 주소에서 SMTP가 지원되지 않음을 의미한다고 말했습니다. 이 문장은 세 계층을 하나로 결합했습니다: 등록된 번호, 관리자가 게시한 구성, 그리고 프로세스의 현재 상태. 이 계층들은 종종 정렬됩니다. WKS는 실제 시도를 허용하기 전에 그 정렬을 요구하는 비용을 드러냈습니다.

좌표로 쓰인 호스트 목록

WKS는 서비스 인스턴스의 이름을 붙이지 않았습니다. 특정 32비트 인터넷 주소에서 특정 프로토콜에 대한 서비스를 기술했습니다. 여러 주소를 가진 기계는 여러 레코드를 필요로 했습니다. TCP와 UDP를 모두 지원하려면 별도의 레코드가 필요했습니다. 오너 이름은 레코드를 찾는 데 도움을 주었지만, 가용성 주장 자체는 문자 그대로의 IPv4 주소에서 끝났습니다.

비트맵은 조밀했습니다. 그 크기는 실제 제공되는 서비스 수가 아니라 표현되는 가장 높은 포트에 의해 결정되었습니다. 포트 25와 80만 광고하더라도 80까지의 모든 중간 위치가 필요했습니다. 뒤따르는 0 옥텟은 생략할 수 있었지만, 높은 위치의 설정 비트 하나가 접두어 전체를 레코드 안으로 끌어당겼습니다. 관심 대상이 잘 알려진 포트의 작은 범위였을 때는 경제적인 표현이었고, 서비스 위치가 임의의 포트와 이동 가능한 인스턴스를 의미하게 되면 덜 자연스러워졌습니다.

이 형식은 또한 이진 질문에만 답했습니다. 두 주소 간의 우선순위도, 동료 간의 상대적 가중치도, 대상 호스트 이름도, 비트 위치와 별개의 대체 포트도, 유지보수 상태를 위한 필드도 없었습니다. 여러 WKS 레코드가 여러 주소/프로토콜 조합을 나열할 수는 있었지만 클라이언트 선택 정책을 구성하지는 않았습니다.

그렇다고 이 설계가 어리석지는 않습니다. 초기 인터넷은 이미 Assigned Numbers를 통해 프로토콜과 포트 번호를 조율했습니다. 관리자가 영역 데이터를 호스트와 동기화해 둔다면, WKS는 익숙한 서비스 목록을 분산 이름 시스템을 통해 그대로 노출할 수 있었습니다. 작은 세계에 적용된 최소 초기 사양이었습니다: DNS 봉투를 재사용하고, 포트 네임스페이스를 재사용하고, 문자 그대로의 주소 하나를 추가하고 나머지는 비트가 담당하게 하십시오.

어려움은 비트를 해석하는 것이 아니었습니다. 비트가 어떤 권위를 지니는지를 결정하는 일이었습니다.

메일 라우팅이 목록을 믿었을 때

1986년 1월에 발행된RFC 974는 메일 라우팅에서 WKS에 실질적인 역할을 부여했습니다. 모든 MX 레코드에 대해 WKS 질의를 수행해 해당 도메인이 원하는 메일 서비스를 지원하는지 확인하도록 강하게 권장했습니다. 지원하지 않는 MX 후보는 폐기하도록 했습니다.

이 절차는 부정적 WKS 근거를 운영적으로 만들었습니다. SMTP 표시의 부재는 연결이 시도되기 전에 호스트를 전달 계획에서 제거할 수 있었습니다. 이상적인 관리 모델에서는 쓸모없는 작업을 절약했습니다: DNS는 이미 대상이 SMTP를 실행하지 않는다는 것을 알고 있었습니다. 불완전한 배포에서는 완전히 다른 일이 벌어졌습니다. “이 사이트의 영역이 완전하고 최신의 WKS 목록을 게시한다”는 주장과 “이 서비스는 존재하지 않는다”는 주장을 혼동했던 것입니다.

이 두 진술은 동등하지 않습니다. 사이트가 SMTP를 실행하면서도 WKS를 게시하지 않을 수 있습니다. MX 레코드를 갱신하면서 관련 비트맵을 잊을 수 있습니다. DNS와 호스트 구성이 서로 다른 관리자에게 속할 수 있습니다. 보조 서버나 리졸버 캐시가 이전 버전을 보유할 수 있습니다. 대상은 레코드가 만들어진 뒤에 서비스를 획득했을 수 있습니다. 어느 조건이든 메일러의 관점에서 누락된 비트를 거짓 음성으로 만들 수 있습니다.

긍정적 비트에도 한계가 있었습니다. 게시와 사용 사이에서 프로세스는 멈출 수 있습니다. 패킷 필터는 경로를 거부할 수 있습니다. 주소는 다른 기계로 이동할 수 있습니다. 다른 애플리케이션이 포트를 차지할 수 있습니다. SMTP 리스너가 응답하다가 프로토콜 진행 중에 실패할 수 있습니다. DNS 캐싱은 매 요청마다 원 출처를 확인하지 않고 데이터를 유용하게 유지하도록 의도적으로 허용합니다; 그 경제성이야말로 DNS 레코드가 살아 있는 프로브가 아닌 이유입니다.

교정은 시도하라는 지시로 도착했다

1989년 10월에RFC 1123은 운영 결과를 기록했습니다. 애플리케이션은 주소에서 모든 서비스를 정확히 나열한 WKS 레코드를 발견하는 것에 의존해서는 안 됩니다. 인터넷 사이트들이 이 타입을 자주 사용하지 않았기 때문입니다. 그 확인 규칙은 무뚝뚝했습니다: 서비스를 사용해 보십시오.

메일에 특화된 교정도 똑같이 직접적이었습니다. 이후의 경험은 WKS가 널리 지원되지 않음을 보여 주었으므로, MX 처리에서의 WKS 단계는 사용해서는 안 됩니다. 표준 역사에는 이렇게 깔끔한 반전이 드물게 존재합니다. RFC 974는 WKS를 유용한 필터로 취급했습니다. RFC 1123은 그 필터를, 피하려던 연결 시도 자체보다 더 위험한 것으로 취급했습니다.

이는 모든 WKS 레코드가 거짓이라는 선언이 아니었습니다. 잘 관리된 레코드는 구성된 서비스를 정확히 기술할 수 있었습니다. RFC 1123은 타입 11을 DNS에서 지우지도 않았습니다. 현재IANA DNS 파라미터 레지스트리는 여전히 WKS를 “well known service description”으로 할당합니다. 코드 포인트의 할당을 유지하는 것은 상호운용성을 보존하고 재사용을 막습니다; 이는 현재의 채택을 인증하는 것이 아닙니다.

변화는 추론에 관한 것이었습니다. 애플리케이션은 긍정적 레코드를 힌트로 사용할 수 있지만, WKS 커버리지가 보편적이거나 완전하다고 안전하게 가정할 수는 없습니다. 선택적이고 드물게 게시되는 목록의 부재는 엔드포인트에서 수집한 근거를 대신할 수 없습니다. 거짓 음성의 비용이 배달되지 않은 메일일 때, 프로토콜을 시도하는 것이 더 신뢰할 수 있는 검증이었습니다.

하나의 서비스 주장 뒤에 숨은 다섯 개의 권위

겉보기 사실을 더 작은 것들로 분리하면 WKS가 더 명확해집니다.

첫째, 번호 할당 권위는 네임스페이스를 조율합니다. TCP 포트 25는 SMTP와 연관되어 있어 독립적으로 작성된 시스템들이 서로 호환되지 않는 목적에 같은 번호를 무심코 부여하지 않게 합니다. 이는 조율에 관한 주장이지 기계에 대한 관찰이 아닙니다.

둘째, DNS 영역 운영자는 주소, 프로토콜, 비트맵을 게시합니다. 이는 DNS 권위와 TTL 안에서의 행정적 주장입니다. DNS 데이터로서는 진실할 수 있으면서 오래되었거나 운영적으로 잘못될 수 있습니다.

셋째, 호스트 운영자는 프로세스가 포트를 바인드할지를 통제합니다. 설정된 비트는 프로세스를 시작할 수 없고, 유지할 수 없으며, 그것이 의도된 구현임을 보장할 수 없습니다.

넷째, 네트워크 정책은 클라이언트가 리스너에 도달할 수 있는지를 통제합니다. 방화벽, 라우팅, 접근 규칙은 같은 서비스를 한 지점에서는 사용 가능하고 다른 지점에서는 사용 불가능하게 만들 수 있습니다. 전역 DNS 응답에는 경로별 허가를 위한 필드가 없습니다.

다섯째, 애플리케이션 프로토콜이 무엇이 응답했는지를 확정합니다. 열린 TCP 포트는 SMTP를 인증하지 않고, 사용자를 승인하지 않으며, 메시지 수용의 성공을 증명하지 않습니다. 그 사실들은 연결과 프로토콜 교환, 보안 메커니즘에서 나옵니다.

이후RFC 6335는 레지스트리 경계를 명시했습니다. 서비스 이름이나 포트의 할당은 보증이 아니며, 할당된 포트의 트래픽이 좋은 트래픽일 필요도, 할당된 서비스일 필요도 없습니다. 관리자는 등록만이 아니라 트래픽에 대한 지식으로 정책을 적용해야 합니다. 이 경고는 WKS보다 새롭지만, 비트맵이 유혹했던 범주 오류를 지적합니다: 공통의 번호는 런타임 신원이 아닙니다.

SRV가 바꾼 것—그리고 바꾸지 않은 것

RFC 2782는 다른 서비스 위치 지정 문제를 다루었습니다. SRV 질의는 도메인 내에서 서비스와 전송 방식을 지명합니다. 그 레코드는 Priority, Weight, Port, Target을 제공합니다. 대상은 서비스 레코드에 매립된 32비트 주소가 아니라 주소 레코드를 가진 호스트 이름입니다. 여러 레코드가 선호 호스트와 백업 호스트를 구분하고 첫 선택을 동료들에게 분산할 수 있습니다.

이는 WKS 대비 상당한 표현력의 단절입니다. 서비스를 비트 위치에서 추론할 필요가 없어졌습니다. 해당 대상을 위해 선택된 포트에서 실행될 수 있습니다. 이름 붙은 호스트들 사이를 이동할 수 있습니다. 클라이언트는 하나의 주소에 대한 무차별적 목록 대신 경계가 있는 선택 절차를 받습니다.

이후 RFC 6335는 SRV 같은 메커니즘이 런타임에 포트를 발견하는 경우 서비스 이름을 고정 포트 할당 없이 등록할 수 있도록 했습니다. 서비스의 명명과 포트의 번호 매기기는 연관되어 있지만 분리 가능한 행위가 되었습니다. WKS는 이 둘을 융합해 있었습니다: 서비스가 곧 번호 매겨진 비트였습니다.

그러나 SRV는 살아 있는 건강 신탁이 되지 않았습니다. 그 우선순위와 가중치는 게시된 구성이지 현재의 큐 깊이가 아닙니다. 대상은 응답이 캐시된 뒤에 실패할 수 있습니다. 클라이언트는 여전히 해석하고, 연결하고, 애플리케이션을 검증해야 합니다. 따라서 역사적 이동은 불신뢰한 DNS에서 전지적인 DNS로의 이동이 아니었습니다. 빈약한 서비스 주장에서 더 정밀한 책임 분담으로의 이동이었습니다.

출처, 산술, 한계

이 서술은 폐쇄된 공식 자료 집합을 사용합니다. WKS의 최초 사양으로 RFC 883, MX 선택에서의 역할로 RFC 974, 유지된 와이어 형식으로 RFC 1035, 운영적 반전으로 RFC 1123, 이후 서비스 위치 지정 대비로 RFC 2782, 서비스 이름과 포트 레지스트리 경계로 RFC 6335, 그리고 타입 11의 지속 할당으로 IANA를 사용합니다.

조밀한 비트맵에 대한 관찰은 지정된 비트 위치에서 직접 따릅니다. 실제 배포에서 절약되거나 낭비된 대역폭을 측정하지는 않습니다. 이 자료들은 현재의 WKS 질의량, 이를 게시하는 영역 수, 지원하는 리졸버, 현재 어떤 서비스가 이에 의존하는지를 드러내지 않습니다. 또한 특정 역사적 레코드가 오래되었다는 것, 모든 메일러가 RFC 974를 따랐다는 것, SRV가 모든 용도를 대체했다는 것을 증명하지 않습니다.

WKS는 실패가 판독 가능했기 때문에 여전히 가치가 있습니다. 이 레코드는 살아 있는 운영 질문에 캐시된 행정 데이터로 답하려 했습니다. 인터넷이 게시가 스파스하다는 것을 배운 뒤, 누락된 비트는 안전한 거부권으로서 기능을 멈췄습니다. 클라이언트는 기술에서 실험으로의 경계를 넘어 실제 연결을 만들어야 했습니다.