brunch

You can make anything
by writing

C.S.Lewis

by Younggi Seo Jun 24. 2019

DNS-The Internet's Directory

도메인 네임 시스템 - 인터넷의 주소 서비스

HTTP, FTP 그리고 SMTP, DNS 프로토콜은 응용계층(7 계층)의 이것이 (1) 클라이언트-서버 패러다임을 사용하는 끝단 시스템 간에 통신을 운용하기 위한 프로토콜이다. 그리고 (2) 끝단 통신 간의 DNS 메시지를 전송하기 위한 단대단(end-to-end) 전송 프로토콜에 의존한다. 하지만 이 DNS의 역할은 웹, 파일 전송, 그리고 이메일 전송과는 꽤 다른 역할을 지닌다. 이러한 응용계층의 전송과는 달리 DNS는 사용자와 바로 상호 접촉하는 응용계층의 프로토콜이 아니다. 대신에 이 DNS는 핵심적인 인터넷 기능을 제공한다. 그 기능이란, 사용자 응용 프로그램과 인터넷의 다른 소프트웨어를 위한 그들이 요구한 IP 주소에 해당하는 호스트 질의를 전송해주는 것이다. 우리는 네트워크의 끝단에 위치한 인터넷 아키텍처 상의 많은 복잡성을 섹션 1.2에서 언급했다. 이 DNS는  네트워크 상의 끝단에 위치한 클라이언트와 서버가 사용하는 '이름-주소 번역 프로세스'라는 중요한 과정을 수행하며 아직 이러한 시스템 운용에 관한 철학을 디자인한 또 다른 사례는 없다.  



2.4.2 DNS 작업 과정 개관


우리는 호스트명에서 IP주소로의 번역 서비스에 관해 중점을 두며 DNS 작업 과정의 높은 수준의 개관을 진행하려 한다.


사용자의 호스트에서 가정컨대 어떤 응용프로그램(웹브라우저나 메일 구독)은 호스트명에서 IP주소로의 전송을 필요로 한다. 이 응용프로그램은 그 클라이언트 사이드의 DNS에게 도와달라고 간청(질의)한다. 번역이 필요로 하는 구체적인 호스트명에 대해서 말이다. (많은 UNIX 운영체제의 기기에서 gethostbyname() 이 번역을 수행하기 위한 호출 프로그램의 콜 함수이다.


...(중략)...


그래서 사용자 호스트 내에서 질의를 하는 응용 프로세스의 관점으로부터 DNS는 간결하고 바로 이루어지는 번역 서비스의 블랙박스형 시스템이다. 하지만 사실, 이 블랙박스가 수행하는 서비스는 복잡하고 수많은 개수의 DNS 서버들이 전 세계적으로 분산되어 구성되어 있다. 이 DNS 서버와 질의하는 호스트의 통신을 구체화시켜주는 응용계층 프로토콜처럼 말이다.


DNS 서버를 공부하기 위한 간단한 디자인은 하나의 DNS 서버에 모든 맵핑이 담겨있을 수도 있다는 가정하에 가능하다. 이 중앙집중형의 디자인은 클라이언트들이 간단하게 모든 질의(쿼리)를 하나의 DNS 서버로 한다는 것을 지시할 때이며, 그리고 이 DNS 서버는 질의했던 클라이언트에게 즉각적으로 응답한다. (이론상 구체적인 과정을 살펴보기 위해 마치 순서대로 진행되는 것처럼 보여도 실제로 DNS 쿼리는 일시에 일어난다. -역주) 비록 이 디자인의 간단함이 쉽게 이해가 되더라도 이것은 오늘날 인터넷에는 부적절하다. 오늘날의 인터넷은 그것의 거대한(그리고 증가하는) 호스트 수와 함께하기 때문이다. 중앙집중형의 디자인의 포함된 문제는 다음과 같다.   


A single point of failure. 만약 이 DNS 서버의 서비스가 중단된다면, 전체 인터넷의 접속 또한 중단된다!

Traffic volume. 하나의 DNS 서버가 모든 DNS 쿼리들을 다룰 수 있다. (모든 HTTP 요청과 e-mail 메시지들이 수백만의 호스트로부터 생성된다.)

Distant centralized database. 한 DNS 서버는 질의한 모든 클라이언트로 "종료를 원함"을 보낼 수 없다. 만약 우리가 하나의 DNS 서버를 뉴욕에 놓는다면, 호주로부터의 모든 질의도 전 세계의 다른 지역으로 날아갈 수 있어야 한다. 아마도 너무 느리거나 혼잡해질 것이다. 이것은 심각한 지연을 일으킬 것이다.

Maintenance. 이 하나의 DNS 서버가 모든 인터넷 호스트의 증적(로그 남김)을 유지해야만 할 것이다. 이 중앙집중형 데이터베이스만 비대해지는 것이 아니라, 모든 새로운 호스트의 사용기록은 빈번히 업데이트되어야만 한다.  



요약하면, 중앙에 단 한 개의 데이터베이스로 집결되는 DNS 서버는 쉽게 말해 범위 확장성(Scale)이 없다. 결과적으로 이 DNS는 아키텍처 디자인에 의해 분산이 가능하다. 사실, 지금 우리가 사용하고 있는 전 세계의 DNS 아키텍처가 인터넷에서 수행할 수 있는 "데이터베이스를 어떻게 분산하는지"의 예는 훌륭하다.



A Distributed, Hierarchical Database

일독 일해 번역하기가 구차하여, 바로 역자가 간단히 재구성한 내용으로 편집하였다.  


일전에 필자가 근무하는 사이트에서 자탐한 IP가 KT DNS 서버인 줄 모르고 차단한 적이 있었다. 다행히 주말이어서 본인이 속한 기관의 홈페이지에 접속 이상은 한동안 없었다. 왜냐하면, DNS Caching(로컬)에 저장된 매핑 DNS 데이터는 보통 이틀 간은 유지되기 때문에 외부에서 접속하는 데는 문제가 없기 때문이다. 하지만 사이트에서 각 시군의 사이트 접속 여부를 표시하는 모니터링 프로그램에서 KT DNS를 사용하는 대다수의 시군 홈페이지가 '접속 중단'이라는 에러가 나타났다. 물론 직접 해당 사이트의 도메인을 입력하면, DNS Caching 때문에 또 홈페이지는 이상 없이 화면에 렌더링 되었다.


주말 그 시각을 기점으로 접속 중단이라고 표시되는 시군의 보안담당자들에게 홈페이지 중단에 대한 문의를 문자메시지로 보냈다. 그중에 한 시군 홈페이지 관리자에게 전화가 왔었는데, 본인이 관리하는 시군의 장비에는 별다른 특이사항이 없다는 응답을 받았다. 그래서 우리 사이트에서 뭔가 특이사항이 없는지 물어봐왔고, DNS(53) 프로토콜의 쿼리 패킷이 시군 공인망에서 우리 사이트로 나올 때 사라진다는 것이었다. 이때까지 본인이 외부 DNS 서비스 IP를 차단한 것을 감지하지 못하고 있었던 나는 현문우답으로 일단 전화를 끊었다.






 









  









  

매거진의 이전글 포트 차단 정책이 필요한 공격 탐지
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari