DNS는 왜 인터넷의 전화번호부가 되었을까?

인터넷 주소창에 익숙한 이름을 입력하면 우리는 거의 즉시 원하는 웹사이트에 도착한다. 화면 뒤에서 수많은 장비가 움직이고 있다는 사실을 의식할 필요도 없다. 그러나 컴퓨터는 우리가 입력한 이름만 보고 목적지를 찾아가지 못한다. 컴퓨터가 실제 통신에 사용하는 것은 이름이 아니라 숫자로 이루어진 IP 주소이기 때문이다.

앞선 글에서 살펴본 TCP/IP가 서로 다른 컴퓨터와 네트워크가 대화하기 위한 공통 규칙이었다면, 이번 글에서 다룰 DNS는 그 대화 상대의 주소를 찾아주는 안내 체계라고 할 수 있다. 사람에게 익숙한 이름과 컴퓨터에게 필요한 숫자 주소 사이에는 생각보다 거대한 번역 시스템이 놓여 있다. 우리는 그 시스템을 DNS(Domain Name System)라고 부른다.

한줄 요약

DNS는 사람이 기억하기 쉬운 도메인 이름을 컴퓨터가 통신에 사용하는 IP 주소로 연결해 주는 인터넷의 분산형 주소 안내 체계이다.

숫자만으로 인터넷을 사용해야 했던 시절

오늘날 우리는 검색 사이트나 언론사, 쇼핑몰의 이름을 기억할 뿐 해당 서버의 IP 주소를 외우지 않는다. 하지만 인터넷의 초기에는 연결된 컴퓨터가 많지 않았기 때문에 각 컴퓨터의 이름과 주소를 하나의 목록에 기록해 관리하는 방식도 가능하였다. 대표적인 것이 HOSTS.TXT라는 파일이었다. 네트워크에 새로운 컴퓨터가 추가되거나 주소가 변경되면 중앙에서 이 파일을 수정하고, 각 기관은 최신 파일을 내려받아 자신의 컴퓨터에 반영하였다.

작은 연구망에서는 이 방식이 비교적 단순하고 효과적이었다. 등록된 컴퓨터가 수십 대 또는 수백 대에 불과하다면 하나의 주소록을 함께 사용하는 것도 큰 문제가 아니었다. 그러나 ARPANET을 비롯한 네트워크에 대학과 연구소, 정부기관의 컴퓨터가 계속 연결되면서 상황이 달라졌다. 새 컴퓨터가 등록될 때마다 중앙 목록을 수정해야 했고, 여러 기관이 동시에 같은 이름을 사용하려 하거나 오래된 파일을 보유하면서 주소가 일치하지 않는 문제도 발생하였다.

무엇보다 모든 정보를 한곳에서 관리하는 구조는 인터넷의 성장 속도를 따라갈 수 없었다. 수천 대, 수만 대의 컴퓨터가 연결되는 환경에서 하나의 관리기관이 전 세계의 이름과 주소를 일일이 등록하고 배포하는 것은 현실적이지 않았다. 인터넷에는 더 많은 주소가 필요했던 것이 아니라, 주소를 나누어 관리하면서도 어디에서나 같은 결과를 얻을 수 있는 새로운 질서가 필요하였다.

폴 모카페트리스가 제안한 새로운 주소 체계

이 문제를 해결하는 과정에서 등장한 인물이 폴 모카페트리스(Paul Mockapetris)였다. 당시 USC 정보과학연구소에서 일하던 그는 하나의 중앙 파일에 모든 이름을 기록하는 방식을 대신하여, 인터넷의 이름 정보를 여러 영역으로 나누어 관리하는 체계를 설계하였다. 1983년 11월 발표된 RFC 882와 RFC 883에는 도메인 이름의 개념과 이름 서버의 동작 방식이 정리되었다. 이것이 오늘날 DNS의 출발점이 되었다.

DNS가 특별했던 이유는 단순히 문자 이름을 숫자 주소로 바꾸었기 때문만은 아니었다. 핵심은 계층형 구조와 분산 관리에 있었다. 모든 주소를 하나의 거대한 명부에 넣는 대신 인터넷의 이름 공간을 여러 단계로 나누고, 각 영역의 관리 권한을 해당 기관에 위임하였다. 국가나 조직의 종류를 나타내는 상위 영역 아래에 기관의 이름을 두고, 그 아래에 서비스나 컴퓨터의 이름을 배치하는 방식이었다.

예를 들어 하나의 도메인이 여러 부분으로 나뉘어 있다면 가장 오른쪽에 있는 영역부터 상위 체계를 형성한다. ‘.com’, ‘.org’, ‘.kr’과 같은 최상위도메인 아래에 조직이나 서비스의 도메인이 등록되고, 그 조직은 다시 자신에게 필요한 하위 도메인을 운영할 수 있다. 중앙은 최상위 질서만 유지하고 세부 정보는 각 관리자가 책임지는 구조였다. 인터넷이 계속 커져도 전체 주소록을 다시 작성할 필요가 없는 확장 가능한 설계였다.

짧은 생각

DNS의 진짜 가치는 이름을 편리하게 만든 것보다 관리 권한을 나누었다는 데 있다고 생각하였다. 인터넷은 하나의 거대한 중앙 시스템으로 성장한 것이 아니라, 각자가 맡은 영역을 관리하면서 도 서로 연결될 수 있었기 때문에 지금의 규모에 도달할 수 있었다.

DNS는 어떻게 원하는 서버를 찾아갈까?

사용자가 브라우저 주소창에 도메인을 입력하면 컴퓨터는 먼저 해당 주소를 이미 알고 있는지 확인한다. 운영체제나 브라우저 내부에 이전 조회 결과가 남아 있다면 그 정보를 다시 사용할 수 있다. 저장된 정보가 없다면 컴퓨터는 통신사나 회사, 공공 DNS 서비스가 운영하는 재귀 DNS 서버에 주소를 물어본다. 사용자를 대신해 여러 이름 서버를 찾아다니며 최종 답을 구하는 역할이다.

재귀 DNS 서버도 답을 모른다면 가장 먼저 DNS 계층의 출발점인 루트 네임서버에 질문한다. 루트 서버가 모든 웹사이트의 IP 주소를 직접 보관하고 있는 것은 아니다. 대신 해당 도메인의 마지막 부분을 관리하는 최상위도메인 서버가 어디에 있는지를 알려준다. 전화번호 안내원이 최종 번호를 바로 말하는 대신 어느 지역의 안내소에 문의해야 하는지를 알려주는 것과 비슷하다.

다음으로 재귀 DNS 서버는 ‘.com’이나 ‘.kr’과 같은 최상위도메인(TLD) 네임서버에 질문한다. 이 서버는 해당 도메인의 상세 정보를 관리하는 권한 있는 네임서버의 위치를 알려준다. 마지막으로 권한 있는 네임서버에 도착하면 도메인에 연결된 실제 IP 주소를 확인할 수 있다. 재귀 DNS 서버는 이 주소를 사용자의 컴퓨터에 돌려주고, 그제야 브라우저는 해당 서버와 TCP/IP 통신을 시작한다.

이 과정은 여러 단계를 거치지만 대부분 매우 짧은 시간 안에 끝난다. 사용자는 주소창에 이름을 한 번 입력하였을 뿐이지만, 그 순간 뒤에서는 로컬 저장정보 확인, 재귀 서버 요청, 루트 서버 조회, 최상위도메인 확인, 권한 서버 응답이라는 주소 탐색이 이루어진다. DNS는 인터넷 통신 자체를 수행하는 장치가 아니라 통신을 시작할 정확한 목적지를 찾아주는 선행 절차라고 볼 수 있다.

매번 처음부터 찾지 않게 만드는 캐시

DNS가 도메인을 조회할 때마다 루트 서버부터 최종 네임서버까지 같은 과정을 반복한다면 인터넷은 지금보다 훨씬 느리고 비효율적일 것이다. 이를 줄이기 위해 DNS는 이전에 확인한 결과를 일정 시간 동안 저장하는 캐시(Cache)를 사용한다. 재귀 DNS 서버가 어떤 도메인의 IP 주소를 한 번 알아냈다면 같은 질문이 다시 들어왔을 때 저장된 결과를 즉시 돌려줄 수 있다.

캐시가 유지되는 시간은 DNS 정보에 설정된 TTL(Time To Live)에 의해 결정된다. TTL이 남아 있는 동안에는 저장된 주소를 사용할 수 있지만 시간이 만료되면 다시 권한 있는 네임서버에 질문해 최신 정보를 확인한다. TTL이 길면 DNS 서버의 부하와 조회 시간을 줄일 수 있지만 주소를 변경했을 때 새로운 정보가 반영되기까지 시간이 걸릴 수 있다. 반대로 TTL이 짧으면 변경 사항은 빠르게 퍼지지만 DNS 조회는 더 자주 발생한다.

웹사이트의 서버를 이전하거나 도메인 설정을 변경한 뒤 사용자마다 접속 결과가 다르게 나타나는 이유도 캐시와 관련이 있다. 어떤 DNS 서버는 이미 새 주소를 받아들였지만, 다른 서버에는 이전 주소의 TTL이 아직 남아 있을 수 있다. 흔히 ‘DNS 전파를 기다린다’고 표현하지만 실제로는 하나의 변경 정보가 전 세계로 동시에 방송되는 것보다, 각 DNS 서버가 저장하고 있던 캐시의 유효시간이 끝나는 과정에 가깝다.

캐시는 단순한 속도 향상 기능이 아니다. 반복되는 요청이 루트와 상위 DNS 서버에 집중되는 것을 막아 전체 인터넷의 부하를 분산한다. DNS의 계층형 구조가 관리의 규모를 해결하였다면 캐시는 조회량의 규모를 해결하였다. 분산된 관리 구조와 재사용 가능한 조회 결과가 결합되면서 DNS는 거대한 인터넷에서도 빠르게 동작할 수 있었다.

DNS가 멈추면 인터넷도 사라지는 것처럼 보인다

DNS에 장애가 발생하더라도 인터넷 회선과 웹서버 자체가 반드시 멈추는 것은 아니다. 서버는 여전히 IP 주소를 가지고 있고 네트워크 역시 패킷을 전달할 수 있다. 하지만 사용자가 입력한 도메인을 IP 주소로 바꾸지 못하면 브라우저는 어느 서버로 접속해야 하는지 알 수 없다. 건물과 도로가 그대로 존재하더라도 주소 안내 체계가 사라져 목적지를 찾지 못하는 상황과 같다.

이러한 중요성 때문에 DNS는 공격자의 표적이 되기도 하였다. 가짜 DNS 정보를 주입하여 사용자를 다른 사이트로 유도하거나, DNS 서버에 과도한 요청을 보내 정상적인 조회를 방해할 수 있다. 사용자는 주소창에 올바른 도메인을 입력했는데도 공격자가 만든 사이트로 이동할 수 있으므로 DNS 정보의 신뢰성은 인터넷 보안과 직접 연결된다.

이를 보완하기 위해 등장한 기술이 DNSSEC(Domain Name System Security Extensions)이다. DNSSEC는 DNS 응답에 디지털 서명을 적용하여 전달받은 정보가 권한 있는 관리자가 제공한 정보인지, 중간에서 변경되지 않았는지를 검증할 수 있도록 하였다. 다만 DNSSEC가 통신 내용을 암호화하거나 악성 웹사이트 자체를 차단하는 것은 아니다. DNS 응답의 출처와 무결성을 확인하는 기술로 이해하는 것이 정확하다.

DNS는 평소 화면에 드러나지 않지만 거의 모든 인터넷 활동보다 먼저 작동한다. 웹사이트를 열고, 이메일 서버를 찾고, 온라인 서비스를 연결하는 과정에서 이름을 주소로 바꾸는 일이 반복된다. 따라서 DNS 장애는 인터넷이 존재하면서도 사용할 수 없는 것처럼 느끼게 만든다. 보이지 않는 주소 체계가 인터넷의 접근성과 신뢰성을 함께 떠받치고 있는 셈이다.

TCP/IP가 길을 만들었다면 DNS는 목적지를 알려주었다

TCP/IP는 서로 다른 네트워크와 컴퓨터가 같은 규칙으로 데이터를 주고받을 수 있게 하였다. 그러나 통신 규칙이 마련되었다고 해서 사람이 모든 서버의 숫자 주소를 기억할 수 있는 것은 아니었다. 인터넷이 연구기관 중심의 작은 네트워크를 넘어 수많은 조직과 개인이 사용하는 공간으로 성장하려면 사람이 이해할 수 있는 이름 체계가 필요하였다.

DNS는 이 문제를 중앙집중식 거대 주소록이 아니라 계층적이고 분산된 구조로 해결하였다. 루트 영역은 전체 이름 공간의 출발점을 유지하고, 최상위도메인과 각 기관은 자신이 맡은 영역을 관리한다. 사용자는 이러한 구조를 알지 못해도 하나의 도메인만 입력하면 세계 어디에 있는 서버든 찾아갈 수 있다. 복잡한 기술이 사용자에게는 단순한 이름 하나로 압축된 것이다.

오늘날 ‘인터넷의 전화번호부’라는 표현은 DNS를 설명할 때 자주 사용된다. 이해하기 쉬운 비유이지만 DNS는 고정된 전화번호 책보다 훨씬 역동적이다. 주소 정보가 계속 변경되고, 관리 권한이 여러 조직에 나뉘며, 캐시를 통해 조회 결과가 재사용된다. 또한 웹서버뿐 아니라 이메일 전달, 서비스 위치 확인, 보안 정책 등 다양한 정보도 DNS 레코드 안에서 관리된다.

결국 인터넷의 발전은 더 빠른 컴퓨터를 만드는 것만으로 이루어지지 않았다. 서로 다른 컴퓨터가 대화하는 규칙, 데이터를 나누어 보내는 방법, 그리고 상대방을 찾아가는 이름 체계가 함께 완성되어야 하였다. TCP/IP가 인터넷의 길을 만들었다면 DNS는 그 길 끝에 있는 목적지를 알려주었다. 우리가 주소창에 이름 하나만 입력하고도 원하는 정보에 도착할 수 있는 이유가 여기에 있다.

짧은 생각

사람들은 인터넷의 속도를 이야기할 때 통신망이나 서버의 성능을 먼저 떠올린다. 그러나 목적지의 주소를 찾지 못하면 아무리 빠른 길도 출발할 수 없다. DNS는 눈에 잘 보이지 않지만 인터넷을 사용할 수 있는 공간으로 완성한 중요한 발명인 셈이다.