요약

  • RFC 1788은 역방향 DNS 트리에만 의존하는 대신, ICMP 타입 37과 38을 사용해 각 유니캐스트 엔드포인트에 직접 도메인 이름을 요청하는 방안을 제안했습니다.
  • 식별자, 시퀀스 번호, 발신 주소 규칙, TTL, 그리고 부정 응답의 범위는 한 번의 응답에 국한되었으며, 이는 개인의 신원, 소유권, 경로 승인 또는 보편적 신뢰를 입증하지 못했습니다.
  • RFC 6918은 이후 이 메시지들이 널리 구현되거나 배포된 적이 없다는 점을 근거로 폐기 예정(deprecated)으로 지정하며, 이 역사의 결정적 사실은 ‘MUST’라는 단어가 아니라 채택이었음을 보여주었습니다.

상태 변경이 이야기를 말한다

현재 IANA ICMP 레지스트리는 타입 37과 38에 각각 Domain Name Request와 Domain Name Reply라는 짧은 설명과 함께 deprecated(폐기 예정) 표시를 달아두고 있습니다. 이 간결한 표는 더 긴 논쟁의 결말입니다. RFC 1788은 1995년 4월 이 두 메시지를 도입하면서 모든 호스트와 라우터가 서버 기능을 구현하도록 요구했습니다. 2013년 표준 트랙으로 발표된 RFC 6918은 이 메시지들이 널리 구현되거나 배포된 적이 없다고 밝히고, 공식적으로 deprecated로 지정하며 RFC 1788을 폐기했습니다.

이후의 문서는 잘못된 필드를 발견한 것이 아니라, 부재하는 생태계를 기록한 것입니다. 할당된 번호, 규범적 문구, 완성된 패킷 다이어그램을 갖춘 프로토콜이라도, 이를 의존 가능한 애플리케이션으로 만들 상호운용 가능한 시스템의 집단이 없다면 안전하게 의존할 수 없습니다.

이 구분이 중요한 이유는 RFC 1788이 실제 결함에 대응한 제안이었기 때문입니다. 완벽한 기존 기술에 밀려 패배한 무의미한 제안이 아니었습니다. 역방향 주소-이름 정보는 종종 불완전했고, 클래스 없는 주소체계(CIDR)의 도입으로 역방향 트리의 위임이 순방향 명명 계층과 달라졌습니다. 이름을 표시하거나 기록하려는 애플리케이션은 긴 DNS 실패를 기다려야 했습니다. 문제는 존재했습니다. 제안된 권한 경로만이 공통 인프라가 되지 못했습니다.

역방향 DNS의 두 개의 행정적 이음선

도메인 이름 체계(DNS)에서 순방향 이름과 역방향 주소 매핑은 반드시 같은 위임을 따르지 않습니다. 어떤 이름은 조직의 일반 도메인 아래에 있지만, 그에 대응하는 역방향 존은 주소 공간 할당을 따를 수 있습니다. RFC 1788은IN-ADDR데이터가 안정적으로 관리되지 않았고, CIDR로 인해 이 행정적 불일치가 더 두드러졌다고 지적했습니다.

이 메모의 답은 구조적인 것이었습니다. 주소 자체에게 물으라는 것. 하나의 유니캐스트 목적지로 ICMP Domain Name Request를 보내고 그 목적지로부터 Domain Name Reply를 받는 방식입니다. 명명 행정은 주소 할당을 따를 수 있고, 라우팅은 요청을 해당 주소를 사용하는 기계로 전달함으로써 데이터베이스를 ‘색인’할 수 있습니다.

그러나 이것은 이음선을 옮긴 것이지 행정을 없앤 것이 아닙니다. 엔드포인트에는 어떤 이름을 보고할지 아는 소프트웨어가 여전히 필요했습니다. 운영자에게는 메시지를 허용할 정책이 여전히 필요했습니다. 애플리케이션에는 최신성과 신뢰를 해석하는 능력이 여전히 필요했습니다. 라우팅은 응답하는 인터페이스를 찾아줄 수 있지만, 그 경로가 응답에 대한 증명서는 아니었습니다.

하나의 주소, 하나의 요청, 하나의 제한된 응답

RFC 1788은 요청에 타입 37, 응답에 타입 38을 할당했습니다. 식별자와 시퀀스 번호는 응답에 그대로 복사되어 요청자가 응답과 쿼리를 연관시킬 수 있게 했으며, 메모는 두 필드 모두 0을 허용했습니다. 각 IP 목적지마다 별도의 요청이 전송되었습니다.

응답의 발신 주소는 요청의 목적지 주소와 반드시 일치해야 했습니다. 이것은 중요한 범위 규칙이었습니다. 주소 A로 보낸 쿼리는, 편의상 주소 B에서 발신된 응답으로 충족될 수 없었습니다. 이 규칙은 패킷 교환을 주소가 지정된 인터페이스에 연결했습니다.

그러나 그것이 인터페이스를 관찰자가 원하는 모든 신원에 연결한 것은 아닙니다. 어떤 사람이 그 기계를 운영하는지, 어떤 법인이 소유하는지, 경로가 승인되었는지, 순방향 DNS 이름이 역으로 가리키는지, 오늘 진실을 말하는 소프트웨어가 내일도 같은 진실을 말할지를 입증하지 않았습니다. 이러한 주장들은 별도의 근거를 필요로 합니다.

RFC 792는 이미 더 넓은 ICMP 경계를 설명한 바 있습니다. ICMP는 문제와 제어 정보를 보고하지만 IP를 신뢰 가능하게 만들지는 않으며, 원본 데이터그램도 ICMP 응답도 반환이 보장되지 않습니다. 따라서 잘 구성된 직접 이름 응답은 한 번의 교환에 대한 영수증이지, 전역적 가용성 약속이 아니었습니다.

이름이 없다는 것조차 하나의 응답이어야 했다

가장 알기 쉬운 응답은 아무것도 담지 않은 것이었습니다. RFC 1788은 0개 이상의 완전 수식 도메인 이름(FQDN)을 허용했습니다. 엔드포인트가 이름을 알지 못하더라도 여전히 응답해야 했으며, 그 빈 결과는 알려진 이름이 없다는 권위 있는 표시로 설명되었습니다.

‘권위 있는’이라는 단어는 과잉 해석될 수 있습니다. 제안된 프로토콜 내에서 이 단어는 침묵과 의도적인 부정 응답을 구분했습니다. 애플리케이션은 요청이 사라졌는지 기다리며 의심할 필요가 없었습니다. 그러나 이것이 부정 결과를 DNSSEC 서명된 거부, 소유권 증명 또는 영구 진술로 바꾸지는 않았습니다. 그것은 그 시점의 엔드포인트가 제공한 제한된 응답이었습니다.

여러 이름이 알려져 있다면 모두 나열해야 했습니다. 그러나 패킷 크기는 물리적 한계를 부과했습니다. 응답 MTU에 담기에 너무 큰 이름은 생략되었습니다. 따라서 결과 집합은 엔드포인트 기준으로 의도적으로 완전하면서도 전송선 기준으로는 불완전할 수 있었습니다. 형식과 경로의 제약은 근거의 일부였습니다.

응답에는 TTL(time to live)도 담겼습니다. 역사적 이유로 부호 있는 2의 보수 값이었습니다. TTL은 수신된 명명 정보를 얼마나 재사용할 수 있는지 소비자에게 알려주었습니다. 그러나 이름이 의미적으로 올바른지, 응답 소프트웨어가 조직을 대변할 권한이 있는지, 이 한 노드를 넘어 배포가 존재하는지를 입증할 수는 없었습니다.

멀티캐스트가 드러낸 보편성의 비용

이 프로토콜은 명시적으로 유니캐스트 전용이었습니다. 브로드캐스트나 멀티캐스트 목적지로 전송된 요청은 조용히 폐기해야 했습니다. 모든 수신 대기 중인 기계가 그룹 주소 쿼리에 응답한다면, 하나의 패킷이 응답 폭풍을 일으킬 수 있었습니다.

이 규칙은 ‘모든 호스트와 라우터’라는 표현 안에 숨겨진 운영 비용을 드러냅니다. 보편적 구현은 모든 전달 방식에 대한 보편적 응답을 의미하지 않았습니다. 공유 메커니즘에는 매우 제한적인 트리거가 필요했습니다. 단일 주소에 대한 별도 쿼리, 단일 응답 경로, 그리고 팬아웃이 트래픽을 증폭할 수 있을 때의 침묵이 그것이었습니다.

그 경계 안에서조차, 보편적 서버 구현은 야심적인 의존성이었습니다. 유용한 전역 서비스는 운영체제, 라우터, 임베디드 장치, 방화벽, 진단 도구, 애플리케이션이 수렴하도록 요구했습니다. RFC 1788은 진단 용도로 이 메커니즘에 대한 애플리케이션 인터페이스를 호스트가 제공해야 한다고도 밝혔습니다. RFC는 이 모든 동작을 명세할 수 있었지만, 코드를 배포하거나 그 모든 현지 정책을 협상할 수는 없었습니다.

보안은 제안되었을 뿐, 라우팅이 공급하지 않았다

RFC 1788은 엔드포인트에 직접 묻는 방식이IN-ADDR데이터에 의존하는 것보다 더 안전할 수 있다고 주장했습니다. IPsec이 교환을 보호할 수 있다고 언급하고, 순방향 DNS에서 얻은 암호학적 서명이 응답을 인증할 수 있다고 제안했습니다. 이것들은 메커니즘을 보호하기 위한 방향 제시였지, 기본적인 요청과 응답이 자동으로 공급하는 속성은 아니었습니다.

메모 자체가 결정적인 단서를 달았습니다. 라우팅은 보안이 아닙니다. 어떤 주소로의 전달은 당시 라우팅 상태에서 네트워크가 패킷을 어디로 보냈는지 확립할 뿐입니다. 접두어의 정당한 통제권, 신뢰할 수 있는 소프트웨어, 합법적 소유권, 또는 안정적인 조직적 정체성을 확립하지 않습니다.

이 경계는 이후 실험적 IPv6 노드 정보 명세인 RFC 4620에서 더 명시적으로 다듬어졌습니다. RFC 4620은 이 메커니즘을 진단, 디버깅, 네트워크 관리로 제한하면서 DNS를 전역적 권위로 남겨두었습니다. nonce, 기본 범위 제한, 개인정보 지침, 속도 제한을 도입했습니다. 학습한 정보는 추가 인증 없이는 보안 결정을 지지해서는 안 된다고 경고하고, 노드 이름 응답에는 TTL 0을 요구했습니다.

RFC 4620은 이전 IPv4 제안을 인용했지만, RFC 1788이 새 번호 아래 조용히 살아남은 것은 아닙니다. 그 축소된 목적과 보호 장치들은, 직접 노드 정보를 진단 도구로서 방어 가능하게 만드는 데만 얼마나 많은 작업이 필요했는지를 보여줍니다.

강제 문장이 자발적 네트워크를 만났을 때

RFC 1788에서 가장 날카로운 문장은 모든 호스트와 라우터가 서버 기능을 구현해야 한다고 선언한 것이었습니다. 명세 언어로 읽으면, 선택적 서버 계층은 없었습니다. 인터넷에 대한 예측으로 읽으면, 그 예측은 실패했습니다.

RFC 6918은 이 실패에 대해 신중했습니다. 아무도 구현을 작성한 적이 없다고 말하지 않았습니다. 이 메시지들이 널리 구현되거나 배포된 적이 없다고 말했습니다. 이것이 정확한 주장입니다. 기록은 하나의 보편적 원인을 제공하지 않으며, 이를 어리석은 저자나 악의적 운영자에 대한 도덕적 우화로 다시 쓰지 말아야 합니다.

동기를 발명하지 않고도 몇 가지 구조적 마찰은 보입니다. 이 제안은 방대하고 이질적인 엔드포인트 집단에 새로운 코드 경로를 요구했습니다. 방화벽과 미들박스는 익숙하지 않은 ICMP 타입을 필터링할 수 있었습니다. 애플리케이션에는 이미 DNS 인터페이스가 있었습니다. 직접 응답은 자체적인 인증, 개인정보, 명명 문제를 도입했습니다. 지연을 피하려던 메커니즘은 충분한 노드가 응답할 때까지 의존 가능한 것으로 취급될 수 없었지만, 노드와 애플리케이션은 의존 가능한 사용이 존재하기 전까지는 투자할 이유가 거의 없었습니다.

이후 폐기 지정이 인센티브를 다시 바꾸었습니다. RFC 6918은 타입을 deprecated로 표시하는 것이 필터링을 지지할 수 있다고 언급했습니다. 레지스트리가 운영자에게 어떤 메시지가 폐기되었다고 알리면, 이를 수용하거나 생성하는 것을 정당화하기가 더 어려워집니다. 표준 기록은 단순히 배포 평형 상태를 설명한 것이 아니라, 남은 경로를 닫는 데 일조했습니다.

실행되는 코드가 진짜 표였다

Lu Heng의 Running-Code Primacy는 이 역사에 유용한 현대적 렌즈를 제공합니다. 인터넷 조정의 정당성은 자발적 기술적 채택에서 시작됩니다. 제안은 독립적으로 통제되는 시스템이 이를 구현하고 계속 상호운용할 때 운영적 권위를 획득합니다. 발행은 설계가 명세되었다는 증거이지, 세계가 채택했다는 증거가 아닙니다.

RFC 1788은 이 구분을 이례적으로 측정 가능하게 만듭니다. 상징적 계층에는 RFC 번호, 할당된 ICMP 타입, 보편적 규범 요구사항이 있었습니다. 운영적 계층에는 공통 서비스를 지탱할 만큼 충분한 배포된 응답자가 없었습니다. 2013년, 상징적 계층은 운영적 계층과 일치하도록 개정되었습니다.

Minimum Initial Specification, Localized Future Decision, Voluntary Adoption 프레임워크는 두 번째 질문을 던집니다. 요구된 공통 계약이 현지 구현자가 선택할 만큼 충분히 작고 유용했는가? RFC 1788의 패킷 형식은 간결했지만, 배포 계약은 그렇지 않았습니다. 보편성은 거의 모든 호스트와 라우터가 새로운 응답 표면을 노출하는 것에 달려 있었습니다. 작은 패킷이 반드시 작은 조정 부담을 의미하지는 않습니다.

이것은 회고적 비교이며, 1995년 저자들이 Lu Heng의 용어를 공유했다는 증명이 아닙니다. 또한 표준에 ‘MUST’가 없어야 한다는 뜻도 아닙니다. 규범적 요구사항은 채택된 프로토콜 안에서 필수적입니다. 범주 오류는 단어의 강도를 채택 경계가 이미 넘어졌다는 증명으로 취급하는 것입니다.

역사는 겸손한 규칙으로 끝납니다. 엔드포인트의 직접 응답은 유용한 근거가 될 수 있습니다. 하나의 행정적 의존성을 줄이고 침묵보다 더 깔끔한 부정 결과를 만들 수 있습니다. 그러나 인터넷 전역의 서비스는 모든 엔드포인트를 책임자로 선언한다고 만들어지지 않습니다. 구현이 응답하고, 네트워크가 메시지를 운반하고, 애플리케이션이 응답의 한계를 보존하고, 운영자가 계속해서 이 메커니즘을 선택할 때에만 존재합니다. 그 경합에서, 실행되는 코드는 RFC 1788을 위반하지 않았습니다. RFC 1788이 지배할 세계가 존재하는지를 결정했습니다.

출처