이름과 주소 사이

www.google.com을 브라우저 주소창에 입력하면 페이지가 뜹니다. 그런데 컴퓨터가 실제로 접속하는 것은 www.google.com이 아닙니다. IP 주소입니다. 142.250.196.100 같은 숫자 덩어리로 패킷을 보내야 합니다. 그렇다면 우리가 입력한 이름과 실제로 필요한 주소 사이에는 누군가가 번역을 해줘야 합니다. 그 번역가가 DNS(Domain Name System)입니다.

이름이 필요한 이유

IP 주소는 기억하기 어렵습니다. 142.250.196.100과 www.google.com 중 어느 쪽을 더 쉽게 외울 수 있는지는 물어볼 필요도 없습니다. 게다가 서버의 IP 주소는 바뀔 수 있습니다. 데이터센터를 이전하거나, 클라우드 공급자를 변경하거나, 부하 분산을 위해 여러 IP를 사용할 수 있습니다. 이름이 고정되어 있으면 IP가 바뀌어도 사용자는 같은 이름으로 접속하면 됩니다.

전화번호부 비유

DNS를 가장 직관적으로 설명하는 비유는 전화번호부입니다. 누군가에게 전화를 걸 때 우리는 상대방의 이름을 알고 있습니다. 전화번호는 전화번호부에서 찾습니다. DNS는 인터넷의 전화번호부입니다. 이름을 알려주면 주소를 돌려줍니다.

단, DNS는 전화번호부보다 훨씬 규모가 큽니다. 전 세계에 등록된 도메인 이름은 수억 개가 넘습니다. 이것을 한 곳에 모아 두면 단일 장애 지점이 되고 트래픽도 감당할 수 없습니다. 그래서 DNS는 계층적으로 분산되어 있습니다. 이 구조는 다음 절에서 살펴봅니다.

IP 주소와 이름의 관계

DNS가 해주는 핵심 작업을 정방향 조회(forward lookup)라고 합니다. 이름을 주면 IP 주소를 돌려줍니다. 반대로 IP 주소를 주면 이름을 돌려주는 것은 역방향 조회(reverse lookup)라고 합니다. 서버 로그에서 접속한 컴퓨터의 이름을 알아낼 때 사용합니다.

DNS가 돌려주는 정보를 레코드(record)라고 부릅니다. 가장 기본적인 것이 A 레코드입니다. A 레코드는 도메인 이름과 IPv4 주소를 연결합니다. IPv6 주소를 연결하는 것은 AAAA 레코드입니다. 이 외에도 메일 서버 주소를 알려주는 MX 레코드, 별칭(alias)을 만드는 CNAME 레코드 등 다양한 종류가 있습니다.

조회가 일어나는 순간

사용자가 브라우저에서 주소를 입력하는 순간부터 페이지가 뜨기 전까지, DNS 조회는 이미 완료되어 있어야 합니다. 브라우저는 HTTP 요청을 보내기 전에 먼저 DNS로 IP 주소를 알아냅니다. 이 조회 과정이 느리면 페이지 로딩도 느려집니다. 그래서 DNS 캐싱이 중요합니다. 한 번 알아낸 결과를 일정 시간 동안 저장해 두면 매번 물어볼 필요가 없습니다.

다음 절에서는 DNS가 전 세계 수억 개의 이름을 어떻게 계층적으로 관리하는지 살펴봅니다.