요약

  • RFC 830은 도메인을 서비스 지점 주소까지 해석한 뒤, Application Interface Process가 사용 가능한 전송과 애플리케이션에 대해 별도의 협상을 수행하도록 제안했습니다.
  • 출처 서버는 가장 오른쪽 레이블부터 계층을 따라 내려갔습니다. 중간 저장소는 로컬이며 서로 분리된 채 유지되었고, 구성 요소 간 교환에는 공통 형식이 부여되었습니다.
  • RFC 882와 883은 영역(zone), 권한, 참조, 캐시, 갱신을 갖춘 타입이 지정된 자원의 분산 저장소를 선택했습니다. 그러나 이 선언적 응답은 곧바로 실행의 증거가 되지는 않았습니다.

하나의 이름 뒤에 있는 두 가지 질문

RFC 830 모델에서 완전한 이름으로 서비스를 요청하는 것은 두 가지 질문을 던지는 일이었습니다. 첫 번째는 행정적 질문이었습니다. 어떤 서버가 목적지 도메인을 대표하는가? 두 번째는 운영적 질문이었습니다. 이 도메인은 현재 요청에 대해 어떤 전송과 어떤 애플리케이션을 제공할 수 있는가?

두 질문이 섞이는 것이 자연스러워 보이는 이유는, 독자가 네임 서비스에 최종 주소를 기대하기 때문입니다. System for Internet Name Service, 즉 SINS는 더 일찍 멈췄습니다. 애플리케이션과 무관한 그 도메인 서비스는 종단 도메인에 연결된 DNS의 주소를 반환했고, 이어서 애플리케이션 인터페이스가 역할을 이어받았습니다.

이 분할은 RFC 819의 설계를 따랐습니다. 도메인은 명명과 번역의 관할 구역이지, 토폴로지에 대한 강제적 서술이 아니었습니다. 조직은 자기 하위 도메인을 관리하면서 서로 다른 내부 규약을 유지할 수 있었습니다. 절대 이름은 공통 참조점을 제공했을 뿐, 모든 로컬 결정을 흡수해서는 안 되었습니다.

경로는 오른쪽에서 시작했다

제안된 이름은 로컬 부분을 앞에 두고, 가장 구체적인 것부터 가장 일반적인 것까지 도메인들을 나열했습니다. 도메인 부분을 해석하기 위해 출처의 DNS는 가장 오른쪽 레이블, 즉 상위 도메인의 레이블부터 시작했습니다.

이 DNS는 축의 역할을 했습니다. 상위 도메인 서버의 주소를 알고 그곳에 다음 단계를 물었습니다. 각 중간 서버는 자기 직속 하위 도메인을 알았습니다. 다음 서버의 주소로 응답하거나, 요청을 한 번 전달할 수 있었습니다. 그러나 RFC는 중간 서버가 지속적인 축이 되는 것은 거부했습니다. 이 제약은 프로토콜을 단순하게 만들고 경로 조율을 출처 근처에 유지했습니다.

따라서 분산은 전역 복사본에 의존하지 않았습니다. 종단 DNS는 상위 도메인들의 작은 목록을 유지했고, 각 중간 서버는 직속 자녀들의 대응 관계만 보유했습니다. 필요한 내용들은 서로 겹치지 않았고, 변경은 로컬에 머물 수 있었습니다.

RFC 830은 공통 저장소 형식조차 요구하지 않았습니다. 두 도메인은 네트워크 계약을 지키는 한 서로 다른 방식으로 테이블을 저장할 수 있었습니다. 정규화는 내부 표현이 아니라 관측 가능한 경계에서 이루어졌습니다.

인터페이스는 실제 기능을 물었다

종단 DNS에 도달하는 것만으로 애플리케이션에 닿을 수는 없었습니다. 출처 프로세스는 자신의 AIP에 완전한 이름과 원하는 서비스를 넘겼습니다. 도메인 해석 후 출처 AIP는 목적지 AIP에 접촉하여 문서가 'what-can-you-do-for-me'라고 부른 협상을 열었습니다.

메시지는 TCP 또는 UDP, 애플리케이션 프로토콜, 서비스 유형을 지정할 수 있었습니다. 긍정 응답은 서비스 하나와 주소를 담았습니다. TCP 예시에서 주소는 IP 주소, 프로토콜 번호, 포트를 모아 담았습니다. 여러 주소가 반환될 수 있었고, RFC는 출처에 선택권을 남기므로 이 복수성을 선호했습니다.

이 선택은 등가성의 약속이 아니었습니다. 멀티호밍 도메인의 두 주소는 서로 다른 경로를 따르거나 서로 다른 상태에 있을 수 있었습니다. 응답은 말합니다. 여기에 종단 지점이 선언한 가능성이 있다고. 그러나 이렇게 말하지 않습니다. 각각이 성공할 것이라고.

가장 독특한 응답은 유용한 비호환이었습니다. 출처는 파일 전송을 위해 NIFTP를 요청했습니다. 목적지는 이 기능에 대해 FTP만 제공했습니다. 출처도 FTP를 안다면 협상은 이 공통 지반을 선택할 수 있었습니다. 목표는 전송 그대로였고, 특정 프로토콜만 바뀌었습니다.

살아 있는 대화는 허가가 아니었다

AIP 대화는 목적지 프로세스가 무엇을 선언하는지에 대한 고정 항목보다 더 최신의 정보를 제공했습니다. 그러나 이는 사용자의 신원, 서비스 사용 권한, 가용 용량, 다음 작업의 성공을 어느 것도 증명하지 않았습니다.

증거는 순차적으로 남았습니다. 올바른 해석이 애플리케이션 거부로 이어질 수 있었습니다. 호환되는 협상 뒤에 전송 실패가 올 수 있었습니다. 연결이 수립된 뒤 비즈니스 오류로 끝날 수 있었습니다. 어느 결과도 나머지를 소급해 다시 쓰지 않았습니다.

이 분리는 권한도 보호합니다. 도메인의 상위는 이름을 위임할 수 있었습니다. 도메인은 자기 서비스 지점의 주소를 공표할 수 있었습니다. 자기 AIP는 기능을 알릴 수 있었습니다. 구체적인 행위를 수용하는 것은 오직 애플리케이션의 정책뿐이었습니다. '가능하다'는 단어는 이 모든 권한을 함께 실어 나르지 않았습니다.

얇은 부분은 저장소에 있었고, 프로토콜에는 없었다

SINS는 여러 쌍, 즉 애플리케이션/AIP, AIP/DNS, AIP/AIP에 공통 명령 구조를 채택했습니다. 요소들은 이름, 서비스, 주소 또는 주석을 표시했습니다. 부정 응답은 이름에서 해석되지 않은 부분을 보여주고 실패를 설명할 수 있었습니다.

영구 저장소는 가볍고 로컬이었지만, 분산된 대화는 상세했습니다. 이는 일관된 선택입니다. 상호 운용 시점에 이해되어야 하는 것만 공통화합니다. 그러나 비용도 있었습니다. 모든 종단 도메인은 협상 지능을 갖추고 서비스 어휘를 공유해야 했습니다.

캐시는 또 하나의 한계를 드러냈습니다. RFC 830은 트랜잭션마다 완전한 해석을 반복하는 것이 비효율적임을 알고 있었습니다. 구현이 결과를 재사용할 것이라고 가정했지만, 캐시를 규범적 기능으로 만들지는 않았습니다. 로컬 자유가 이겼고, 지속 기간, 만료, 최신 정보와 오래된 정보의 구분은 공통 계약 밖에 남았습니다.

DNS는 다른 공통 계층을 선택했다

RFC 881은 HOSTS.TXT에서 벗어나는 과정을 다루었습니다. 도메인 이름 테이블은 우선 평범한 테이블과 공존해야 했습니다. 나중에 리졸버가 테이블을 읽던 라이브러리 호출을 대체하여, 애플리케이션은 주소가 파일에서 왔는지 서버에서 왔는지 알 수 없게 됩니다. 중앙 파일은 결국 상위 도메인의 서버들만 유지하게 됩니다.

RFC 882와 883은 더 많은 구조를 공통 분산 저장소 안에 놓았습니다. 이름은 정보의 집합을 지정했습니다. 질의는 자원 유형과, 필요하다면 프로토콜 클래스를 추가했습니다. 서버들은 권위 있는 영역과 참조를 보유했습니다. 리졸버는 질문을 계속 추적하고 응답을 캐시에 담았습니다.

권한과 캐시의 구분은 명시적이 되었습니다. 영역은 마스터 데이터와 갱신 절차에서 나왔습니다. 캐시된 데이터는 이전 해석에서 나왔으며 일정 기간 후 사라졌습니다. 같은 바이트가 같은 출처 없이도 유용할 수 있었습니다.

애플리케이션과의 로컬 인터페이스는 더 이상 보편적인 네트워크 프로토콜을 필요로 하지 않았습니다. 프로시저 호출이나 시스템 호출이면 충분했습니다. 공유 계약은 주로 서버 질의, 자원, 참조, 영역 전송, 갱신을 다루었습니다.

버려진 분기가 남겨진 분기를 설명한다

RFC 1034는 RFC 830을 여러 계층적 명명 제안 가운데 하나로 인용합니다. 그리고 분산 저장소와, 이후 DNS로 이어진 경험을 가진 일반화된 자원들은 별도로 RFC 882와 883에 귀속시킵니다. 따라서 SINS를 현대 DNS의 단순한 초안으로 제시하는 것은 틀립니다.

두 설계는 위임을 공유했고 완전한 전역 테이블을 거부했습니다. 차이는 지능을 어디서 공통화하느냐에 있었습니다. RFC 830은 도메인 해석 이후의 살아 있는 협상을 정규화했습니다. DNS는 선언적 자원과 그것을 찾고, 복사하고, 갱신하는 방식을 정규화했습니다.

선언적 데이터는 분산에 적합합니다. 캐시되고, 감사되고, 여러 애플리케이션이 사용합니다. 그러나 그것은 실시간 테스트가 되지 않습니다. 살아 있는 대화는 현재의 대안을 발견할 수 있지만, 의존성, 지연, 공격 표면을 추가합니다. 역사는 항상 한쪽을 선택하라고 명령하지 않습니다. 다만 두 쪽에 같은 증거를 부여하지 말라고 요구합니다.

출처