DNS는 정말 인터넷의 '주소록'일까요?

2016년 10월 21일 금요일 아침, 미국 동부의 수많은 사람들이 잠에서 깨어나 스마트폰으로 트위터를 열려다 같은 화면을 마주했습니다. 페이지가 로딩되지 않았습니다. 넷플릭스도, 스포티파이도, 뉴욕타임즈 홈페이지도 마찬가지였습니다. 재택근무를 준비하던 사람들은 깃허브에 접속하지 못해 코드를 올리지 못했고, 온라인 쇼핑을 하려던 사람들은 페이팔 결제 화면 앞에서 멈춰 섰습니다. 사람들은 각자의 와이파이를 껐다 켜고, 공유기를 재부팅하고, 통신사에 전화를 걸었습니다. 문제는 그들의 집에 있지 않았습니다.

몇 시간 뒤 보안 전문가들이 원인을 밝혀냈을 때, 많은 사람들이 놀랐습니다. 트위터도 넷플릭스도 해킹당하지 않았습니다. 그들의 서버는 멀쩡했습니다. 공격받은 것은 전혀 다른 곳, 이름조차 낯선 회사였습니다. 그리고 그 회사가 하는 일이 무엇인지 알게 되었을 때, 사람들은 인터넷이라는 것이 자신들이 생각했던 것과 다른 방식으로 작동한다는 사실을 처음으로 깨달았습니다.

범인은 트위터도, 넷플릭스도 아니었습니다

공격을 받은 곳은 딘(Dyn)이라는 미국의 작은 회사였습니다. 딘은 사람들이 눈으로 확인할 수 있는 서비스를 운영하지 않았습니다. 대신 트위터, 넷플릭스, 레딧, CNN, 깃허브, 에어비앤비, 사운드클라우드 같은 대형 사이트들을 위해 한 가지 일을 대신 해주고 있었습니다. 사용자가 “twitter.com”이라고 입력했을 때, 그 이름을 실제 서버가 있는 숫자 주소로 바꿔주는 일이었습니다. 이 회사가 마비되자, 이름을 주소로 바꿔줄 곳이 사라졌습니다. 서버는 멀쩡한데, 그 서버로 가는 길을 아무도 안내해주지 못하는 상황이 벌어진 것입니다.

이 공격의 도구는 미라이(Mirai)라는 악성코드였습니다. 보안이 허술한 가정용 CCTV, 공유기, 디지털 비디오 레코더 같은 사물인터넷 기기 수십만 대를 감염시켜 만든 봇넷이었습니다. 공격자들은 이 좀비 기기들을 동원해 초당 1.2테라비트가 넘는 트래픽을 딘의 서버로 쏟아부었습니다. 흥미로운 사실은, 이 정도 규모의 공격을 설계한 사람들이 애초에 노리던 목표가 트위터나 넷플릭스가 아니었다는 점입니다. 미국 연방수사국(FBI)은 이 공격이 애초에는 한 온라인 게임 서버를 겨냥해 시작되었을 가능성이 크다고 보았습니다. 정작 세계 최대 규모의 사이트 수천 곳을 마비시킨 것은, 계획된 국가 배후의 사이버전이 아니라 몇몇 젊은 해커들이 만든 도구가 감당할 수 없을 만큼 커져버린 결과였습니다.

이 사건이 남긴 질문은 단순합니다. 왜 회사 하나가 무너졌다고 인터넷의 절반이 함께 무너졌을까요. 그 답을 이해하려면, 우리가 평소 “DNS는 인터넷의 전화번호부 같은 것”이라고 배워온 설명부터 다시 들여다볼 필요가 있습니다.

주소록이라는 비유, 어디가 부족할까요

이름을 주소로 바꿔준다는 설명 자체는 틀리지 않았습니다. 하지만 종이 전화번호부를 떠올리면 놓치는 부분이 있습니다. 전화번호부는 한 권으로 완결됩니다. 인쇄되는 순간 내용이 고정되고, 바뀐 번호는 다음 판이 나올 때까지 반영되지 않습니다. 누가 관리하는지도 분명합니다. 발행사가 만들고, 발행사가 배포합니다.

DNS는 이 세 가지 성질을 전부 갖고 있지 않습니다. 하나로 완결된 책이 아니라 수백만 개의 서버에 나뉘어 저장된 정보의 그물입니다. 인쇄된 순간 멈추는 것이 아니라 지금 이 순간에도 초당 수십억 번씩 갱신되고 조회됩니다. 그리고 이 전체를 관리하는 단일한 발행사는 존재하지 않습니다. 누군가 이 표현을 쓴다면, 아마도 “끊임없이 스스로를 고쳐 쓰는, 주인 없는 책”에 더 가까울 것입니다. 딘이 무너졌을 때 인터넷 전체가 흔들린 이유도 여기에 있습니다. 이 정보의 그물에서 특정 구간을 담당하는 매듭 하나가 끊어지면, 그 매듭에 의존하던 모든 길이 함께 끊어집니다.

이 그물이 왜 이런 모양으로 만들어졌는지 이해하려면, 인터넷이 지금보다 훨씬 작았던 시절로 돌아가야 합니다.

전화번호부가 감당할 수 없었던 것

1970년대 인터넷의 전신인 아파넷(ARPANET)에는 컴퓨터가 수백 대 정도밖에 연결되어 있지 않았습니다. 이 시절에는 실제로 전화번호부와 비슷한 방식이 통했습니다. 스탠퍼드 연구소(SRI International)가 ‘HOSTS.TXT’라는 하나의 텍스트 파일에 모든 컴퓨터의 이름과 주소를 정리해 관리했고, 새로운 컴퓨터가 연결되거나 주소가 바뀌면 담당자에게 연락해 파일을 고쳐달라고 요청했습니다. 그러면 전 세계의 모든 컴퓨터가 주기적으로 이 파일을 통째로 내려받아 자신의 시스템에 저장해두었습니다.

문제는 인터넷이 예상보다 훨씬 빠르게 커졌다는 데 있었습니다. 연결되는 컴퓨터가 수천 대로 늘어나자 이 파일은 하루가 다르게 몸집을 불렸고, 모든 컴퓨터가 이 파일을 내려받는 데 걸리는 시간과 네트워크 부담도 함께 늘어났습니다. 게다가 파일을 고칠 수 있는 사람은 사실상 한 곳에 몰려 있었습니다. 이름 하나를 바꾸려 해도 중앙 관리자의 손을 거쳐야 했고, 그 관리자가 처리하지 못하는 요청은 그대로 쌓였습니다. 하나의 파일, 한 곳의 관리자에게 의존하는 구조는 수백 대에서는 버틸 수 있어도 수만 대, 수십만 대에서는 무너질 수밖에 없는 설계였습니다.

한 사람이 그린 나무 구조

이 문제를 풀어야 했던 사람은 서던캘리포니아대학교(USC) 정보과학연구소의 폴 모카페트리스(Paul Mockapetris)였습니다. 그의 상사였던 존 포스텔(Jon Postel)은 HOSTS.TXT 방식이 더 이상 지속될 수 없다는 것을 알고 있었고, 모카페트리스에게 새로운 이름 체계를 설계해달라고 맡겼습니다.

모카페트리스가 내놓은 답은 간단하지만 근본적으로 다른 발상이었습니다. 하나의 중앙 파일에 모든 정보를 몰아넣는 대신, 이름 전체를 나무처럼 가지 친 구조로 나누고, 각 가지의 관리 책임을 그 가지를 담당하는 사람에게 넘기자는 것이었습니다. 예를 들어 “누가 .com으로 끝나는 모든 이름을 알고 있어야 하는가”라는 질문에 대해, 이전 방식은 “중앙 파일 하나가 전부 알아야 한다”고 답했다면, 새 방식은 “.com을 담당하는 곳만 알면 되고, 그 안에서 다시 각 회사가 자기 영역만 책임지면 된다”고 답했습니다. 정보를 한곳에 모으는 대신, 책임을 잘게 나누어 각자에게 위임한 것입니다.

1983년 11월, 모카페트리스와 포스텔은 이 구상을 RFC 882, RFC 883이라는 기술 문서로 정리해 발표했습니다. 이름 하나가 이 나무 구조 속에서 몇 단계를 거쳐 해석되는 이 체계에 ‘도메인 네임 시스템’, 줄여서 DNS라는 이름이 붙었습니다. 흥미로운 점은, 이 설계가 처음부터 거창한 국제 표준을 목표로 만들어진 것이 아니라, 한 연구소에서 눈앞의 실무 문제를 풀기 위해 고안되었다는 사실입니다. 그런데 이 구조가 이후 40년 넘게 인터넷 전체를 떠받치는 골격이 되었습니다.

묻고, 또 물어서 찾아가는 방식

이 나무 구조가 실제로 작동하는 과정은 우리가 흔히 상상하는 것보다 훨씬 분주합니다. 사용자가 브라우저에 “twitter.com”을 입력하면, 컴퓨터는 이 이름을 곧바로 알지 못합니다. 대신 평소 사용하는 리졸버(resolver)라는 안내자에게 먼저 묻습니다. 이 안내자도 답을 모르면, 나무의 가장 꼭대기인 ‘루트 서버’에 묻습니다. 루트 서버는 twitter.com의 정확한 주소는 모르지만, “.com을 담당하는 곳이 어디인지”는 알고 있습니다. 그래서 그쪽으로 안내합니다. .com을 담당하는 서버 역시 twitter.com의 정확한 주소는 모르지만, “트위터의 주소를 실제로 관리하는 서버가 어디인지”는 알고 있습니다. 그렇게 몇 단계를 거쳐 마지막에 도달한 서버가 비로소 정확한 숫자 주소를 알려줍니다.

이 과정이 매번 이렇게 여러 단계를 거친다면 몹시 느릴 것 같지만, 실제로는 그렇지 않습니다. 한 번 물어서 찾은 답은 일정 시간 동안 저장해두는 ‘캐시’라는 방식 덕분에, 같은 질문을 반복할 필요가 거의 없기 때문입니다. 그래서 대부분의 조회는 눈 깜짝할 사이에 끝납니다. 전 세계 인터넷 트래픽의 상당 부분이 이런 식으로, 사용자가 전혀 의식하지 못하는 사이에 몇 겹의 위임과 캐시를 거쳐 처리되고 있습니다.

이 구조에서 흔히 오해하는 부분이 하나 있습니다. “루트 서버가 딱 13대뿐이라 위험하다”는 이야기입니다. 실제로 루트 서버의 ‘주소’는 13개로 고정되어 있지만, 그 뒤에 있는 물리적인 컴퓨터는 애니캐스트라는 기술을 이용해 전 세계에 수백 대가 나뉘어 있습니다. 하나의 주소로 요청을 보내도, 요청자와 가장 가까운 곳에 있는 서버가 응답하도록 설계되어 있는 것입니다. 딘 사건에서 진짜 취약점으로 드러난 곳은 이 최상위 루트 서버가 아니라, 대형 사이트들이 한꺼번에 의존하고 있던 특정 민간 업체 하나였습니다. 나무의 뿌리는 튼튼했지만, 특정 가지 하나에 너무 많은 사이트가 매달려 있었던 셈입니다.

구분	종이 전화번호부	DNS
갱신 방식	다음 판 인쇄까지 고정	실시간으로 계속 갱신
관리 주체	발행사 한 곳	나무 구조로 위임된 수많은 관리자
저장 위치	한 권의 책	전 세계에 분산된 서버들
장애 시 영향	책 한 권의 문제로 끝남	특정 지점 장애가 연쇄적으로 확산될 수 있음

이름이 곧 권력이 될 때

DNS를 단순한 기술로만 보면 놓치는 지점이 하나 더 있습니다. 이름과 주소를 연결하는 이 권한은, 누가 어떤 이름으로 인터넷에 존재할 수 있는지를 결정하는 권한이기도 합니다. 이 권한을 오랫동안 사실상 혼자 관리한 사람이 바로 앞서 등장한 존 포스텔이었습니다. 초창기에는 도메인 이름을 배정하고 루트 영역 파일을 손보는 일을 그가 거의 개인적인 신뢰를 바탕으로 처리했습니다. 인터넷이 학술 네트워크에 머물러 있을 때는 이런 방식이 통했지만, 상업적으로 폭발적인 가치를 지니게 되자 한 개인이 쥐고 있기에는 너무 큰 권한이 되었습니다.

그래서 1998년, 이 역할을 여러 나라의 정부, 기업, 시민사회가 함께 참여하는 국제기구인 ICANN(국제인터넷주소관리기구)으로 넘기는 작업이 이루어졌습니다. 포스텔은 이 이양 작업이 마무리된 직후인 1998년 10월, 세상을 떠났습니다. 한 사람의 손에 있던 인터넷 이름 체계의 열쇠가, 여러 주체가 나누어 쥐는 방식으로 넘어간 시점과 그의 마지막이 겹친 셈입니다.

이 이름 체계를 둘러싼 힘의 문제는 지금도 진행형입니다. 어떤 나라는 특정 사이트로 향하는 이름 해석 과정에 개입해 접속을 막는 방식으로 콘텐츠를 통제합니다. 이는 서버를 직접 차단하는 것보다 눈에 덜 띄면서도 효과적인 방법으로 여겨져 왔습니다. 한편에서는 이용자의 검색 기록이 통신사의 DNS 서버를 거치며 노출된다는 우려 때문에, 이 조회 과정 자체를 암호화하는 ‘DNS over HTTPS’ 같은 기술이 등장하기도 했습니다. 이름을 주소로 바꾸는 이 조용한 절차가, 실제로는 검열과 감시, 프라이버시가 부딪히는 지점이라는 사실은 잘 알려져 있지 않습니다.

다시, 2016년 그 아침으로

딘 사건이 있고 몇 시간 뒤, 엔지니어들은 문제가 된 트래픽을 걸러내고 서비스를 하나씩 복구했습니다. 트위터 타임라인이 다시 열리고, 넷플릭스가 다시 재생되었을 때, 대부분의 사용자는 그사이 무슨 일이 있었는지조차 알지 못한 채 하루를 이어갔습니다. 회사 하나가 몇 시간 마비되었을 뿐인데 인터넷의 상당 부분이 함께 흔들렸다는 사실은, 뉴스 몇 줄로 지나가고 잊혔습니다.

하지만 이 구조는 그대로 남아 있습니다. 오늘날에도 세계 수많은 사이트들의 이름 해석은 여전히 소수의 대형 업체에 집중되어 있습니다. 나무처럼 가지를 뻗어 위험을 분산하려 했던 설계가, 그 가지 끝에서는 다시 몇 개의 굵은 줄기에 의존하는 모습으로 돌아온 셈입니다. 우리가 매일 무심코 입력하는 이름 하나하나는, 이렇게 위임에 위임을 거듭한 끝에 조용히 주소를 찾아 돌아옵니다. 그 조용함이 얼마나 정교하게 설계된 결과인지는, 그것이 한순간 멈추기 전까지는 좀처럼 드러나지 않습니다.

자주 묻는 질문

DNS 루트 서버가 13대뿐이라는데, 사실인가요?

‘주소’ 기준으로는 13개가 맞습니다. 하지만 애니캐스트 기술 덕분에 실제로 그 뒤에서 응답하는 물리적인 서버는 전 세계에 수백 대가 분산되어 있습니다. 13이라는 숫자 하나가 곧 서버 한 대를 의미하는 것은 아닙니다.

DNS와 IP 주소는 어떻게 다른가요?

IP 주소는 인터넷에서 컴퓨터를 실제로 찾아가는 숫자 좌표입니다. DNS는 사람이 외우기 쉬운 이름(예: twitter.com)을 이 숫자 좌표로 바꿔주는 체계입니다. 즉 DNS 자체가 주소는 아니며, 이름과 주소를 연결하는 절차에 가깝습니다.

왜 DNS 서버 하나를 공격했을 뿐인데 그렇게 많은 사이트가 함께 마비되었나요?

여러 대형 사이트가 자신의 이름 해석 업무를 같은 업체에 위탁하고 있었기 때문입니다. 2016년 딘 사건에서는 이 업체 하나가 마비되자, 이곳에 의존하던 트위터, 넷플릭스 등 다수의 사이트가 동시에 접속 장애를 겪었습니다.

일반 사용자가 DNS 서버를 직접 바꿀 수 있나요?

가능합니다. 통신사가 기본으로 제공하는 DNS 대신 구글의 8.8.8.8 같은 공개 DNS 서버로 설정을 바꿀 수 있습니다. 다만 이 경우 조회 기록이 어느 회사로 넘어가는지가 달라질 뿐, DNS 자체의 구조가 바뀌는 것은 아닙니다.

DNS는 누가 관리하나요?

특정 국가나 기업이 단독으로 소유하고 있지 않습니다. ICANN이라는 국제기구가 여러 나라의 정부, 기업, 시민사회와 함께 전체 체계를 조율하고, 실제 이름 해석 업무는 수많은 민간 사업자와 기관에 나뉘어 위임되어 있습니다.

메타 설명: 2016년 대규모 인터넷 마비 사태를 통해 DNS의 실체를 짚어봅니다. 단순한 ‘주소록’이 아닌, 위임과 캐시로 이루어진 분산 시스템으로서의 DNS의 역사와 구조를 알기 쉽게 설명합니다.

태그: DNS, 도메인 네임 시스템, 폴 모카페트리스, 미라이 봇넷, Dyn 공격, 인터넷 역사, ICANN

URL 슬러그: dns-internet-address-book-myth

이 글이 도움이 되었다면 주변 사람과 공유해 보세요.