도메인 네임 시스템편집자 확인

도메인 네임 시스템(Domain Name System, DNS)은 인터넷이나 사설 네트워크에서 사용되는 분산 데이터베이스 시스템이다. 사람이 읽을 수 있는 도메인 이름(예: www.example.com)을 컴퓨터가 식별하는 IP 주소(예: 192.0.2.1)로 변환하는 핵심적인 서비스를 제공한다. 이 시스템은 네트워크 통신의 근간을 이루며, 웹 브라우징, 이메일 전송, 파일 전송 등 거의 모든 인터넷 활동의 첫 단계에서 필수적인 역할을 한다.

DNS는 전화번호부와 유사한 기능을 수행한다. 사용자가 브라우저에 도메인 이름을 입력하면, DNS는 그 이름에 해당하는 IP 주소를 찾아내어 사용자의 장치가 올바른 서버와 통신할 수 있도록 안내한다. 이 과정을 이름 해석(Name Resolution)이라고 부른다. DNS가 없었다면, 사용자는 웹사이트에 접속하기 위해 길고 복잡한 숫자 조합인 IP 주소를 직접 기억하고 입력해야 하는 불편함을 겪었을 것이다.

이 시스템의 가장 큰 특징은 계층 구조와 분산 처리 방식에 있다. 전 세계의 모든 도메인 정보를 단일 서버에 집중하지 않고, 전 세계에 흩어져 있는 수많은 네임 서버들이 계층적으로 분담하여 관리한다. 이 구조는 확장성과 내결함성을 높이며, 특정 지점의 장애가 전체 시스템으로 확산되는 것을 방지한다.

DNS는 단순한 변환기 이상의 기능도 수행한다. 다양한 유형의 리소스 레코드를 통해 이메일 서버 위치(MX 레코드), 도메인 별칭(CNAME 레코드), 텍스트 정보(TXT 레코드) 등 다양한 정보를 저장하고 조회할 수 있다. 이는 현대 인터넷 인프라의 복잡한 요구를 지원하는 데 기여한다.

도메인 네임 시스템의 초기 개념은 1970년대 ARPANET에서 시작되었다. 당시 네트워크에 연결된 호스트 정보는 'HOSTS.TXT'라는 단일 텍스트 파일로 중앙에서 관리되었다[1]. 이 파일에는 호스트 이름과 숫자 IP 주소의 매핑이 기록되어 있었고, 네트워크에 참여하는 모든 사이트는 정기적으로 이 파일을 자신의 시스템에 갱신해야 했다. 그러나 네트워크가 급격히 성장함에 따라 중앙 집중식 파일 관리 방식은 병목 현상과 일관성 유지의 어려움을 야기했다.

이러한 문제를 해결하기 위해 1983년 폴 모카페트리스가 이끄는 팀이 새로운 분산형 이름 해석 시스템에 대한 연구 보고서(RFC 882, RFC 883)를 발표했다. 이것이 오늘날 DNS의 공식적인 탄생으로 여겨진다. 이 시스템은 계층적이고 분산된 데이터베이스 구조를 채택하여 관리 부담을 분산시키고 확장성을 극대화했다. 1984년에 버클리 인터넷 네임 도메인 소프트웨어가 개발되어 실질적인 구현과 배포가 시작되었다.

1980년대 후반부터 1990년대에 걸쳐 인터넷이 상업화되고 글로벌하게 확산되면서 DNS는 필수적인 인프라로 자리 잡았다. 1998년 비영리 기관인 ICANN이 설립되어 루트 서버와 최상위 도메인의 정책 조정 및 관리를 담당하게 되었다. 시간이 흐르면서 DNS 프로토콜은 여러 차례 개정되었으며, 특히 보안과 신뢰성을 강화하기 위한 DNSSEC 표준이 개발되고 배포되기 시작했다.

도메인 네임 시스템은 인터넷의 전화번호부 역할을 하는 분산형 데이터베이스 시스템이다. 그 핵심 구성 요소는 크게 계층적인 도메인 이름 공간, 이를 관리하는 다양한 네임 서버, 그리고 실제 정보를 담는 리소스 레코드로 나뉜다. 이 세 요소가 상호작용하여 사람이 읽을 수 있는 도메인 이름을 컴퓨터가 이해하는 IP 주소로 변환하는 기능을 수행한다.

첫 번째 핵심 요소는 도메인 이름 공간과 그 계층 구조이다. 이 공간은 점(.)으로 구분된 라벨의 연속으로 구성되며, 오른쪽에서 왼쪽으로 상위에서 하위로 읽는 트리 구조를 형성한다. 최상위에는 루트 도메인(".")이 존재하며, 그 아래에 최상위 도메인(TLD)인 .com, .org, .kr 또는 .net 등이 위치한다. 각 TLD 아래에는 2차 도메인(예: 'example'), 그 아래에 3차 도메인(예: 'www')이 계층을 이루며, 이를 FQDN(정규화된 도메인 이름)이라고 부른다.

두 번째 핵심 요소는 이 계층 구조의 각 부분을 담당하는 네임 서버이다. 네임 서버는 특정 존(zone)에 대한 정보를 저장하고 제공하는 서버이다. 주요 종류는 다음과 같다.

세 번째 핵심 요소는 리소스 레코드이다. 이는 네임 서버 데이터베이스에 저장되는 실제 정보 단위로, 여러 유형이 존재한다. 가장 기본적인 A 레코드는 도메인 이름을 IPv4 주소로 매핑하고, AAAA 레코드는 IPv6 주소로 매핑한다. CNAME 레코드는 한 도메인 이름을 다른 도메인 이름(별칭)으로 가리키게 하며, MX 레코드는 해당 도메인의 메일 서버를 지정한다. NS 레코드는 해당 도메인 존을 책임지는 권한 있는 네임 서버를 가리키는 데 사용된다.

DNS의 핵심 기능은 사용자가 입력한 도메인 이름을 컴퓨터가 통신에 사용하는 IP 주소로 변환하는 것이다. 이 변환 과정을 '이름 해석' 또는 '네임 리졸루션'이라고 부른다. 일반적인 웹 브라우징 상황을 예로 들면, 사용자가 www.example.com이라는 주소를 입력하면, 운영체제의 리졸버가 먼저 자신의 로컬 DNS 캐시를 확인한다. 캐시에 해당 정보가 없으면, 리졸버는 미리 설정된 재귀 네임 서버(대개 ISP나 공공 DNS 서비스 제공자의 서버)에 질의를 보낸다.

재귀 네임 서버는 질의를 받으면, 루트부터 시작해 계층적으로 필요한 정보를 찾아나간다. 먼저 루트 네임 서버에 www.example.com의 IP 주소를 묻는다. 루트 서버는 .com 최상위 도메인을 관리하는 TLD 네임 서버의 주소를 알려준다. 재귀 서버는 그 주소로 다시 질의를 보내면, TLD 서버는 example.com 도메인을 관리하는 권한 있는 네임 서버의 주소를 응답한다. 마지막으로, 재귀 서버는 해당 권한 있는 네임 서버에 직접 질의하여 최종적으로 www.example.com에 대한 A 레코드나 AAAA 레코드(IP 주소)를 얻는다.

이 과정에서 재귀 서버가 각 단계의 서버에게 최종 답변을 요청하는 방식을 반복적 질의라고 한다. 반면, 사용자의 리졸버가 재귀 서버에게 최종 결과만을 요청하는 방식은 재귀적 질의에 해당한다. 재귀 서버는 얻은 IP 주소를 사용자에게 응답하고, 이후 같은 질의를 빠르게 응답하기 위해 결과를 일정 시간 동안 자신의 캐시에 저장한다. 이 저장 시간은 각 리소스 레코드에 설정된 TTL 값에 의해 결정된다.

전체 이름 해석 과정은 다음과 같은 단계로 요약할 수 있다.

이러한 분산 계층 구조 덕분에 DNS는 전 세계의 수많은 도메인 이름을 효율적이고 안정적으로 관리할 수 있다.

DNS 프로토콜은 TCP와 UDP 두 가지 전송 프로토콜을 사용한다. 표준적인 이름 해석 질의와 응답은 주로 UDP 포트 53을 통해 이루어지며, 이는 낮은 지연 시간과 오버헤드를 제공한다. 그러나 응답 메시지 크기가 512바이트를 초과하거나 영역 전송과 같은 대용량 데이터 교환 시에는 TCP 포트 53을 사용한다.

DNS 메시지는 고정된 12바이트의 헤더와 가변 길이의 네 개의 섹션으로 구성된다. 헤더에는 트랜잭션 ID, 플래그(질의/응답, 재귀 요청/가능 여부 등), 질문/응답/권한/추가 RR의 개수 등의 정보가 포함된다. 네 개의 메시지 섹션은 다음과 같다.

1. 질문 섹션: 해석하려는 도메인 이름과 질의 유형(A 레코드, AAAA 레코드, MX 레코드 등), 클래스를 지정한다.

2. 응답 섹션: 질문에 대한 답변으로 반환되는 리소스 레코드들이 위치한다.

3. 권한 섹션: 응답을 제공한 권한 있는 네임 서버에 대한 레코드를 포함한다.

4. 추가 정보 섹션: 응답에 직접적으로 해당하지는 않지만 관련이 있어 함께 반환될 수 있는 레코드(예: MX 레코드 질의 시 해당 메일 서버의 A 레코드)를 담는다.

DNS 메시지 형식에서 도메인 이름은 라벨 시퀀스로 표현되며, 각 라벨 앞에는 그 길이를 나타내는 1바이트가 온다. 이 방식을 통해 메시지 내에서 동일한 도메인 이름이 반복될 경우, DNS 압축이라는 포인터 메커니즘을 사용하여 중복 전송을 피하고 메시지 크기를 줄일 수 있다.

DNS는 설계 당시 보안을 고려하지 않아 여러 취약점을 내포하고 있다. 가장 대표적인 공격 방식은 DNS 스푸핑과 DNS 캐시 포이즈닝이다. DNS 스푸핑은 공격자가 위조된 DNS 응답을 보내 사용자를 악성 사이트로 유도하는 공격이다. DNS 캐시 포이즈닝은 재귀 네임 서버의 캐시에 잘못된 정보를 주입하여, 해당 서버를 이용하는 모든 사용자의 질의를 조작하는 공격이다. 이러한 공격은 피싱이나 중간자 공격의 초기 단계로 악용될 수 있다.

이러한 보안 문제를 해결하기 위해 표준화된 기술이 DNSSEC(Domain Name System Security Extensions)이다. DNSSEC은 공개 키 암호 방식을 사용해 DNS 응답의 진위를 확인하는 메커니즘을 제공한다. DNS 레코드에 디지털 서명을 추가하여, 응답이 신뢰할 수 있는 출처에서 왔으며 전송 중 변조되지 않았음을 검증할 수 있다. DNSSEC의 주요 기능은 데이터 출처 인증, 데이터 무결성 보장, 부인 방지이다.

DNSSEC의 도입은 복잡한 키 관리와 배포 문제, 그리고 추가적인 계산 부하를 동반한다. 또한, DNSSEC 자체는 데이터의 기밀성을 보장하지 않으며, 전송 구간의 암호화를 제공하지 않는다. 이러한 한계를 보완하기 위해 DoT와 DoH가 개발되었다. 이들은 DNS 질의와 응답을 암호화된 채널을 통해 전송하여, 제3자가 통신 내용을 엿보거나 조작하는 것을 방지한다.

DNS는 다양한 유형의 리소스 레코드를 정의하여 도메인 이름에 대한 다양한 정보를 제공한다. 각 레코드는 특정 목적을 가지며, 도메인 이름을 IP 주소로 변환하는 기본 기능 외에도 이메일 라우팅, 별칭 지정, 서비스 발견 등 여러 중요한 네트워크 서비스를 가능하게 한다.

가장 일반적인 레코드 유형은 다음과 같다.

이러한 레코드들은 복합적으로 활용되어 현대 인터넷 인프라를 구성한다. 예를 들어, 한 웹사이트는 로드 밸런싱을 위해 동일한 도메인에 여러 A 레코드를 설정할 수 있다. CNAME 레코드는 CDN 서비스를 이용할 때 원본 서버를 가리키는 데 자주 사용되며, TXT 레코드는 보안 정책을 공개적으로 선언하는 수단이 된다. 또한 SRV 레코드는 특정 애플리케이션 프로토콜을 사용하는 서비스의 자동 발견을 가능하게 한다. 각 레코드는 TTL 값을 가지며, 이 값은 다른 네임 서버나 리졸버가 해당 정보를 캐시에 보관할 시간을 결정한다.

콘텐츠 전송 네트워크는 지리적으로 분산된 서버 네트워크를 운영하여 웹 콘텐츠를 사용자에게 더 빠르게 전달한다. 이때 DNS는 핵심적인 역할을 수행한다. 사용자가 CDN 서비스를 이용하는 웹사이트에 접근하면, DNS 시스템은 사용자의 IP 주소를 기반으로 지리적으로 가장 가까운 CDN 서버를 식별한다. 그 후 해당 서버의 IP 주소를 사용자에게 반환하여 최적의 경로로 콘텐츠를 제공받을 수 있게 한다. 이 과정은 지연 시간을 크게 줄이고 대역폭 사용을 효율적으로 분산시킨다.

애니캐스트는 동일한 IP 주소를 여러 지리적 위치의 서버에 할당하고, 라우팅 프로토콜을 통해 사용자의 요청을 가장 가까운 서버로 자동 라우팅하는 네트워킹 기술이다. DNS 인프라, 특히 루트 네임 서버와 TLD 네임 서버는 애니캐스트를 광범위하게 활용한다. 전 세계에 분산된 수백 개의 서버 인스턴스가 동일한 IP 주소를 공유하며, 이는 DDoS 공격에 대한 복원력을 높이고 전 세계 어디서나 일관된 응답 시간을 보장하는 데 기여한다.

기존의 DNS 쿼리는 암호화되지 않은 UDP 또는 TCP 패킷을 통해 전송되어, 네트워크 경로 상의 제삼자가 질의 내용과 응답을 감시하거나 조작할 수 있었다. 이 문제를 해결하기 위해 DNS over HTTPS와 DNS over TLS가 등장했다. DoT는 전용 포트(853)를 통해 DNS 트래픽을 TLS 연결로 암호화하는 반면, DoH는 기존 HTTPS 포트(443)를 사용하여 DNS 메시지를 일반 웹 트래픽과 혼합하여 전송한다. 두 기술 모두 사용자의 DNS 쿼리 프라이버시를 보호하고 중간자 공격을 방지하는 것을 목표로 하지만, 네트워크 관리의 어려움과 중앙화 우려 등 논쟁도 존재한다[3].

도메인 이름의 관리와 등록은 계층적 구조에 따라 이루어진다. 최상위 도메인(TLD)을 관리하는 레지스트리와, 최종 사용자에게 도메인 이름 등록 서비스를 제공하는 레지스트라가 핵심 역할을 담당한다. 사용자는 레지스트라를 통해 원하는 도메인 이름을 검색하고, 사용 가능한 경우 일정 기간(보통 1년) 동안 등록한다. 등록 정보는 해당 TLD의 레지스트리 데이터베이스에 저장되며, 이 정보는 전 세계의 DNS 시스템에 공유된다.

등록 절차는 일반적으로 다음 단계를 따른다. 먼저, 레지스트라의 웹사이트에서 도메인 이름의 가용성을 확인한다. 등록 가능한 경우, 등록자(Registrant)의 연락처 정보, 관리자(Administrative), 기술(Technical), 청구(Billing) 담당자 정보를 포함한 후이스(WHOIS) 정보를 제공하고 등록 기간을 선택한 후 결제를 완료한다. 등록이 완료되면, 레지스트라는 레지스트리에 해당 정보를 전송하고, 도메인 이름은 권한 있는 네임 서버의 주소와 함께 글로벌 DNS에 등록된다.

도메인 이름의 관리는 지속적인 과정이다. 등록자는 등록 기간이 만료되기 전에 갱신(Renewal) 절차를 밟아 소유권을 유지해야 한다. 도메인 이름의 소유권 이전(Transfer)은 다른 레지스트라로 옮기는 과정을 말하며, 특정 규칙과 인증 코드(EPP 코드)를 필요로 한다. 또한, 등록 정보의 정확성은 ICANN(국제 인터넷 주소 관리 기관) 규정에 의해 의무화되어 있으며, 부정확한 정보는 도메인 이름의 정지를 초래할 수 있다.

• Wikipedia - 도메인 네임 시스템

• Wikipedia - Domain Name System

• 나무위키 - DNS

• KISA - DNS 기본 동작 원리

• IANA - Root Zone Database

• Google Developers - DNS 개요

• RFC 1034 - Domain Names - Concepts and Facilities

• RFC 1035 - Domain Names - Implementation and Specification