그러면 다른 시스템과 그 사용자들은 이러한 역동적 정보를 위해 등록 시스템으로 질의를 할 수 있을 것이며, 따라서 자원들의 네트워크 어드레스에 관계없이 멤버 호스트 및 자원을 위한 간단한 룩업을 수월하게 할 수 있게 된다. 지금까지 DNS는 이러한 역동적 등록의 이점에서 제외되었는데, 그 이유는 복잡성과 이행의 어려움 때문이었다.
애플컴퓨터 애플톡의 NBP(Name Binding Protocol), 노벨 네트웨어의 SAP(Service Advertising Protocol) 및 마이크로소프트 윈도의 WINS (Windows Internet Naming Service)는 역동적 이름 및 어드레스 등록 서비스의 예다. 이름 등록 서비스 중 주목할 만한 예외는 DNS였는데, 이것은 이름 및 어드레스가 네트워크로 등록되기 위해 정적 구성 파일의 수동 관리 방법을 이용해왔다.
역동적 등록의 이점에도 불구하고, NOS 네이밍 서비스는 대규모 환경에서 중요한 문제가 있었다. 1990년대 왠 구축이 붐을 이루던 시대에 다중서버 노벨 네트웨어 가게를 운영했던 사람이라면 아마도 SAP 필터를 이행하는 데 따른 고통을 실감한 바 있을 것이다.
■ DNS 업데이트하기
분산된 WINS 설치기반에서의 문제 역시 전설적이다. 거꾸로, DNS는 세계에서 가장 크고 분산된 네트워크에서 아주 잘 작동해왔으며, 현재까지 거의 20년 동안 자기 몫을 하고 있다. 따라서 DNS는 데이터 로딩 면에서 많은 관리가 필요할지 모르지만, 다른 어떤 네이밍 서비스도 따라올 수 없을 정도로 복잡한 환경에서 확장성과 기능을 입증 받아온 것이다.
하지만 인터넷 기술이 기업 NOS 플랫폼의 핵심 요소로서 중심을 향해 계속 이동해감에 따라, 역동적 이름 등록 서비스의 필요는 보다 급박하다는 것이 증명되고 있다. 이는 특히 DHCP 같은 기술들이 자동 어드레스 관리용으로 인기를 얻어감에 따라 더욱 심각해지고 있다. 어드레스가 매일 바뀔 때, 그 어드레스에 연결된 호스트 이름 또한 이름이 거기에 관련이 있다면 매일 바뀌어야 하기 때문이다.
이 문제에 대한 해결책은 RFC 2136(ftp.is.co.za/rfc/rfc2136.txt)에서 제공되었다. 여기서는 역동적 DNS(dynamic DNS)라는 DNS 프로토콜의 확장판을 이용해 DNS 영역 테이블에서 데이터를 삭제 및 추가하는 메커니즘을 설명하고 있다. 지난 몇 년 동안, 이 부문의 작업은 여러 DNS 서버가 이제 그 프로토콜을 지원하고(대부분의 지원 제품들은 DNS-DHCP 서버로 통합되었다), 클라이언트 운영시스템 또한 이것을 핵심 기술로 이행하기 시작하는 단계로까지 진척되었다.
하지만 불행히도 이 기술은 복잡하고, 안전하게 이행하기가 어려우며, 이 두 가지는 배치의 속도를 매우 늦추는 요인이 되었다. 이들은 개발 작업을 매우 힘들게 할 뿐만 아니라 관리자들이 프로토콜을 둘러싼 문제와 씨름하느라 힘든 시간을 보냈기 때문에 엔드유저 집단 내에서 이 기술의 채택을 더디게 했다. 하지만, 이제 인기 있는 데스크탑 클라이언트들이 적극적으로 이 프로토콜을 수용하고 있기 때문에, 이 기술은 더 이상 피할 수 없게 되었다.
