DNS 조회(DNS Lookup)란 무엇인가?
도메인 네임 시스템 조회, 줄여서 DNS는 사용자가 검색창에 URL을 입력한 순간부터 페이지가 로딩되기까지 사이에서 일어나는 과정을 말합니다. 기술적으로 설명하자면, URL(예: www.google.com)을 IP 주소로 변환하는 프로세스입니다.
IP 주소는 우리 집 주소와 비슷한 개념입니다. 우편물을 보낼 때 주소를 사용하듯이, 컴퓨터는 데이터를 특정 장소로 전송할 때 IP 주소를 사용합니다. IP 주소는 긴 숫자 나열로 되어 있어 기억하기 어렵기 때문에, 컴퓨터는 DNS를 활용해 기억하기 쉬운 URL과 IP 주소 사이를 번역합니다. 인터넷에 연결된 모든 기기는 고유한 IP 주소를 가지고 있습니다.
DNS는 어떻게 작동하는가?
인터넷의 방대한 규모를 감안하면, 컴퓨터가 모든 IP 주소를 메모리에 저장해 둘 수는 없습니다. 대신 브라우저에 www.google.com을 입력하면 컴퓨터는 해당 웹사이트의 IP 주소를 찾아내는 작업을 시작합니다.
먼저 컴퓨터는 '캐시(cache)'라고 불리는 로컬 메모리를 확인합니다. 캐시에는 최근 방문한 사이트들의 IP 주소가 저장되어 있어, 다시 찾아볼 때 더 빠르게 로딩할 수 있습니다. 하지만 최근 방문한 몇몇 사이트만 저장되어 있기 때문에, 대부분의 경우 원하는 IP 주소를 찾지 못합니다.
1단계 (위 다이어그램의 번호와 일치): 다음으로 컴퓨터는 ISP(인터넷 서비스 제공업체)의 로컬 재귀 네임서버에 문의합니다. ISP란 Time Warner Cable, Spectrum, Verizon처럼 인터넷 연결 서비스를 제공하는 업체를 말합니다. 네임서버는 복잡하게 들리지만, 실제로는 "www.google.com의 IP 주소가 무엇인가요?" 같은 DNS 요청에 답변하도록 설계된 서버 소프트웨어일 뿐입니다.
어떤 네임서버든 이 질문에 답할 수 있습니다. IP 주소를 알고 있다면 그대로 응답하고, 모른다면 다른 서버에 물어보라고 안내합니다. 재귀(recursive) 네임서버는 답을 모를 경우 단순히 질의를 다른 곳으로 돌리는 것이 아니라, 스스로 답을 찾는 작업까지 수행한다는 점에서 차별화됩니다. 모든 네임서버가 재귀형인 것은 아닙니다.
2단계: 재귀 네임서버는 먼저 자신의 캐시를 확인합니다. IP 주소가 없다면 루트 네임서버(root nameserver)에 질의합니다. 루트 네임서버는 IP 주소를 직접 알지는 못하지만, 요청을 해석해 재귀 네임서버에게 다음으로 갈 곳을 알려줄 수 있습니다. 모든 재귀 네임서버에는 13개 루트 네임서버의 IP 주소가 미리 설정되어 있으며, 재귀 네임서버는 그중 하나를 골라 같은 질문을 던집니다.
3단계: 루트 네임서버는 요청의 최상위 도메인(TLD), 즉 www.google.com의 경우 '.com' 부분을 읽고, 재귀 네임서버에게 GTLD(Global Top Level Domain) 서버에 물어보라고 안내합니다. GTLD는 '.com', '.net', '.edu' 등 도메인 유형별 참조 목록이라 할 수 있습니다. 웹사이트의 IP 주소 자체는 모르지만, 어떤 네임서버가 그 정보를 보유하고 있는지는 파악하고 있습니다.
4단계: 재귀 네임서버는 GTLD 네임서버에 www.google.com의 IP 주소를 요청합니다.
5단계: GTLD 네임서버는 요청의 다음 부분을 오른쪽에서 왼쪽으로 읽습니다(www.google.com의 경우 'google' 부분). 그리고 권한 있는 네임서버(authoritative nameserver)에 연락하라는 메시지를 되돌려 보냅니다. 권한 있는 네임서버란 해당 도메인을 책임지며 정보의 1차 출처 역할을 하는 네임서버입니다.
6단계: 재귀 네임서버는 권한 있는 네임서버에 같은 질문을 합니다. 기술적으로 서버는 'A 레코드(Address Record)'를 요청하는데, 이것이 바로 서버들이 IP 주소를 지칭하는 방식입니다.
7단계: 이 서버는 드디어 답을 알고 있습니다! IP 주소를 재귀 네임서버에 되돌려주며, 이 답변이 권한 있는 것임을 표시합니다. 재귀 네임서버는 누군가 곧 같은 웹사이트에 접속할 경우를 대비해 IP 주소를 자신의 캐시에 저장합니다. 캐시의 각 항목에는 'TTL(Time to Live)'이 태그되어 있어, 서버가 해당 정보를 얼마나 오래 보관했다가 삭제할지 결정합니다.
8단계: 재귀 네임서버는 컴퓨터에 IP 주소를 알려줍니다. 이번에는 '권한 있음' 표시가 붙지 않는데, 1차 정보 출처가 아니라 단순히 정보를 전달하는 중개자이기 때문입니다.
9단계: 컴퓨터는 방금 받은 IP 주소로 www.google.com에 대한 요청을 보냅니다.
10단계: 해당 주소의 웹 서버가 구글 홈페이지를 반환하고, 페이지가 화면에 로딩됩니다.
이 전체 과정은 단 몇 밀리초 만에 완료되며, 하루에도 수조 번 반복되고 있습니다.
DNS가 최종 사용자에게 미치는 영향
DNS는 인터넷이 작동하는 데 필수적인 요소이기 때문에 해커들의 주요 공격 대상이 됩니다. DNS의 근본적인 문제는 오늘날 우리가 겪는 대부분의 보안 문제와 같습니다. 인터넷과 오늘날 사용하는 많은 기술들은 소수의 연구자들을 위해 설계되었지만, 시간이 지나면서 전 세계가 사용하는 체계로 확장되었습니다. DNS(HTTP를 비롯한 대부분의 프로토콜과 마찬가지로)는 보안을 염두에 두고 설계되지 않았습니다. 그래서 지금은 여러 보안 문제에 대한 수정책을 덧붙여야 하는 상황입니다. 아쉽게도 개발 후반에 덧붙인 보안은 처음부터 내장된 보안만큼 효과적이지 못합니다.
DNS에서 이것이 야기하는 대표적인 문제는 응답을 받을 때 네임서버의 진위 여부를 검증하는 절차가 없다는 점입니다. 따라서 해커는 컴퓨터의 DNS 질의에 악성 응답을 보내, 컴퓨터가 그것을 진짜 DNS 네임서버의 응답으로 믿도록 속일 수 있습니다. 즉, 컴퓨터가 "www.chase.com의 IP 주소가 무엇인가요?"라고 물으면, 해커가 DNS 서버보다 먼저 자신의 악성 사이트 IP 주소로 응답하는 것입니다. 그러면 사이트가 로딩될 때 chase.com처럼 보이지만, 실제로는 해커가 통제하는 가짜 사이트입니다.
이는 피싱과 매우 유사하지만, 사용자가 악성 링크를 클릭하도록 속이는 것이 아니라 방문하려던 웹사이트 자체가 DNS 조회 과정에서 악성 사이트로 연결된다는 점이 다릅니다. 이런 유형의 공격은 훨씬 위험하고 예방하기도 어렵습니다. 결국 사용자가 스스로 경계하여 사이트가 진짜 사이트를 사칭하고 있음을 알아차려야 합니다(링크 주소가 조금 이상하거나, 오탈자나 조악하게 복제된 로고가 있는지 살펴야 합니다). 하지만 이는 매우 어려운 일이며, 사용자가 상당한 수준의 기술적 지식을 갖추고 있어야만 가능합니다.
DDoS 공격과 봇넷
2016년에는 DNS 공격으로 미국 동부 해안 대부분 지역의 인터넷이 거의 하루 종일 마비되는 사태가 벌어졌습니다. 이 사례에서 장애는 DDoS 공격으로 인해 발생했습니다. DDoS(분산 서비스 거부) 공격은 인터넷상의 수천 대의 머신이 동시에 하나의 시스템을 공격하는 방식입니다. 일반적으로 이러한 머신들은 소유자가 모르는 사이에 멀웨어에 감염된 것들로, 한 명 또는 한 그룹의 해커가 모든 머신을 통제합니다. 이렇게 함께 사용되는 감염 머신들의 집합을 '봇넷(botnet)'이라고 부릅니다.
봇넷은 피해 서버에 DNS 요청을 쏟아붓고, 기하급수적으로 늘어나는 요청량이 시스템을 압도하여 서버가 정상적인 트래픽을 처리하지 못하게 만듭니다. 그래서 해커들이 DNS 서버를 공격하는 동안에는 컴퓨터가 IP 주소를 요청해도 서버가 응답할 수 없습니다. 결과적으로 공격이 중단될 때까지 해당 서버가 관리하는(권한을 가진) 사이트에는 접속할 수 없게 됩니다.
이러한 공격은 서버 용량을 과잉 프로비저닝(over-provisioning)하여 초과 수요를 감당할 수 있게 하거나, DNS 방화벽을 구축하는 방식으로 완화할 수 있습니다.
DNSSEC: 근본적인 해결책
DNS가 제기하는 많은 문제를 더 폭넓게 해결하는 방법은 DNSSEC입니다. DNSSEC은 공개키 암호화 기반의 디지털 서명으로 인증을 강화합니다. 요청된 데이터의 소유자가 디지털 서명을 함으로써, 앞서 언급한 위조 응답 상황이 발생할 수 없도록 보장하는 것입니다. 이를 통해 데이터 출처 인증(데이터가 리졸버가 생각하는 출처에서 실제로 왔음을 보장)과 데이터 무결성 보호(전송 중 데이터가 변조되지 않았음을 보장)가 가능해집니다.
아쉽게도 DNS를 근본적으로 고치기 위해서는 DNSSEC의 광범위한 배포가 필요합니다. 네트워크 운영자가 자신들의 재귀 리졸버에서, 도메인 소유자가 권한 있는 서버에서 이를 명시적으로 활성화해야 하기 때문입니다. 아직까지는 충분히 이루어지지 않았지만, DNS가 안고 있는 문제점을 더 많은 사람이 인식하고 변화를 요구함에 따라 조만간 확산되기를 기대해 볼 수 있습니다.