문제의 발단과 해결
원거리의 호스트 컴퓨터를 연결하여 네트워크를 구성하고 통신 및 데이터의 교환이 가능해지자 네트워크에 연결되는 호스트 컴퓨터의 수가 점점 늘어나게 됩니다. 1969년 최초의 접속이 성공한 이후 10여 년이 지나는 동안에 네트워크(ARPANET)에는 약 200개가 안 되는 호스트 컴퓨터가 추가됩니다.
그러나 명부를 관리하는 중앙 컴퓨터에서 ‘호스트 주소 명부(hosts.txt 파일)’를 단순히 업데이트하여 공유하는 기존 시스템으로는 증가하는 호스트 컴퓨터 수로 인한 문제점이 드러나게 됩니다. 1982년 7월에 기록된 RFC814에는 이에 대한 우려가 기록되어 있습니다.
‘현재 25개가 채 안 되는 네트워크와 수백 개 밖에 안 되는 호스트 컴퓨터가 연결되어 있을 뿐입니다. (중략) 그러나 우리가 앞으로 수행해야 할 작업은 훨씬 큰 규모의 인터넷을 가정해야 합니다. 우선 최대치로 약 1,000개의 네트워크와 각 네트워크마다 평균 25개 정도의 호스트 컴퓨터를 가정하고 있는데, 최대 25,000개의 호스트 컴퓨터가 연결된 규모의 인터넷입니다. 현재로는 이 규모가 큰 것인지 작은 것인지 알 수 없습니다. 그러나 현재의 상황만으로도 기존의 호스트 정보를 가진 테이블 운영 방식은 적절치 않으며 새로운 방식의 기술로 미래에 대비해야 합니다.’
조금 구체적으로 살펴보면 다음과 같습니다.
(1) 트래픽과 로드
네트워크에 연결된 호스트 컴퓨터의 정보(호스트 명부)를 얻으려고 중앙 컴퓨터 한대에 접속함으로써 트래픽과 로드의 문제가 발생한다. 또한 중앙 컴퓨터에 문제가 있을 때 접속 리스트를 다운 받을 수 없기에 이를 분산 관리할 필요가 있다.
(2) 호스트 이름의 충돌
동일한 이름의 호스트명이 없어야 하는데 중앙 관리 센터에서는 호스트명에 대한 생성 및 삭제 권한이 없다. 즉, 누군가 호스트 명부 파일에 있는 호스트명과 동일한 이름을 만들어 버리면 이를 통제할 수단이 없다. 특히나 누군가 메이저 메일 허브와 동일한 호스트명을 사용한다면 메일 서비스를 망칠 수 있다.
(3) 업데이트 지연에 따른 정보 불일치
최신 호스트명부의 리스트를 최신의 것으로 유지하는 동안에도 새로운 호스트가 추가되거나 그 정보가 변경될 수 있다.
본질적인 문제는 전체 호스트의 이름을 NIC 한 곳에서 관리하고 배포하고 업데이트하는 매커니즘으로는 호스트 수 증가에 따른 인터넷의 규모를 감당할 수 없다는 것이었다. 아이러니하게도 알파넷의 확장을 이끌었던 hosts.txt 파일을 이용한 인터넷 접속 방식은 이로 인해 종말을 맞이한다.
출처: DNS and BIND
이윽고 ARPANET 운영기구는 네트워크에 연결되는 호스트 컴퓨터 관리자가 스스로 이름을 만들고, 자유로이 변경하면서도 네트워크 내의 모든 호스트 컴퓨터가 그 변경된 정보를 확인하여 데이터를 사용할 수 있도록 하는 시스템에 대한 조사 및 연구에 착수합니다.
