Domain Name System (DNS) 개요

🕓 5 mins read

사실, DNS 시스템에 대한 자세한 내용들은 책을 찾아봐도 되고, 위키를 검색해 보면 아주 상세하게 온갖 정보가 나올 텐데, 간단하게 우리가 시스템 디자인을 하는 데 있어 알아두면 좋을 내용들 위주로 간략하게 정리해 봤습니다.

# 소개

도메인 네임 시스템(DNS)은 인터넷의 핵심 구성 요소로, 외우기 어려운 IP 주소 대신 쉽게 기억할 수 있는 도메인 이름을 사용하여 웹사이트에 액세스 할 수 있게 합니다. DNS는 도메인 이름을 IP 주소로 매핑하는 방법으로 소개되었으며, 사용자가 웹 사이트에 액세스 하고 서버가 서로 찾는 것을 쉽게 하기 위한 방법입니다.

과거에(?) 사람들이 전화번호 외우기 어려우니 전화번호부를 찾아보던 것과 같은 개념이라고 생각하시면 됩니다. (요즘? 사람들은 전화번호부가 뭔지도 모르려나요😅)

 

# DNS 작동방식

DNS hierarchy 구조

DNS는 계층 구조로 구성되어 있으며, 계층 구조의 최상위에는 루트 서버가 있습니다. 루트 서버는 .com, .org, .edu와 같은 최상위 도메인 (Top Level Domain: TLD)을 관리하는 역할을 합니다. 사용자가 브라우저에 도메인 이름을 입력하면, 브라우저는 루트 서버에 도메인 이름이 속한 TLD를 확인하는 요청을 보냅니다. TLD가 확인되면, 브라우저는 해당 TLD의 권한 있는 서버에 도메인 이름과 관련된 IP 주소를 요청합니다.
(눈치채셨겠지만, domain name을 탐색하는 과정은 URL을 오른쪽 끝에서부터 왼쪽으로 읽으면서 탐색하게 됩니다.)

DNS 서버는 루트 서버, 권한 있는 서버, 캐싱 서버 등 다양한 종류가 있습니다. 루트 서버는 TLD를 관리하고 적절한 권한 있는 서버를 가리키는 역할을 합니다. 권한 있는 서버는 특정 TLD 내의 도메인 이름을 관리하고 도메인 이름과 관련된 IP 주소를 제공합니다. 캐싱 서버는 DNS 성능을 향상시키기 위해 이전 DNS 쿼리 결과를 캐싱하는 역할을 합니다.

캐시 레이어에 대해서는 따로 다루도록 하겠습니다.

일반적인 퍼블릭 도메인 접근 과정

# DNS 레코드 유형

도메인 이름을 관리하는 데 사용되는 여러 가지 DNS 레코드가 있습니다. 일반적으로 사용되는 DNS 레코드 중 일부는 다음과 같습니다.

A 레코드: A 레코드는 도메인 이름을 IP 주소로 매핑하는 데 사용됩니다. 예를 들어, 사용자가 "example.com"을 브라우저에 입력하면 A 레코드는 "example.com"과 관련된 IP 주소를 제공합니다.

MX 레코드: MX 레코드는 도메인 이름의 메일 서버를 지정하는 데 사용됩니다. 이메일을 올바른 메일 서버로 라우팅 하기 위해 사용됩니다.

CNAME 레코드: CNAME 레코드는 도메인 이름의 별칭을 만드는 데 사용됩니다. 예를 들어, "example.com"에 웹 사이트가 있고 "example.com/short"에 대한 짧은 URL을 만들고 싶다면 "short"라는 CNAME 레코드를 "example.com"에 만들 수 있습니다.

타입	설명	Key	Value	예시
A	호스트명 -> IP주소 맵핑	Hostname	IP address	[A, relay1.naubull2.io, 104.18.2.118]
NS	도메인명의 권한있는 DNS 호스트명을 맵핑	Domain name	Hostname	[NS, naubull2.io, dns.naubull2.io]
CNAME	별칭(alias)를 정식 호스트명으로 맵핑	Hostname	Canonical name	[CNAME, naubull2.io, server1.primary.naubull2.io]
MX	메일 서버 호스트명을 정식호스트명으로 맵핑	Hostname	Canonical name	[MX, mail.naubull2.io, mailserver1.backup.naubull2.io]

 

# DNS 보안

DNS는 인터넷의 핵심 구성 요소이므로 쉽게 악의적인 공격의 대상이 됩니다. DNS 스푸핑과 캐시 오염이라는 일반적인 DNS 보안 위협만 살펴보겠습니다.

DNS 스푸핑은 공격자가 정상적인 웹 사이트로 가려던 트래픽을 악성 웹 사이트로 재전송하는 것입니다. 이는 DNS 서버를 해킹하거나 위법 DNS 서버를 사용하는 방법으로 이루어집니다.

캐시 오염은 공격자가 DNS 캐시에 있는 정보를 수정하는 것입니다. 이는 정상적인 웹 사이트로 가려던 트래픽을 악성 웹 사이트로 재전송하는 방법으로 이루어집니다.

이러한 위협들에 대비하기 위해 DNSSEC과 DNS over HTTPS라는 보안 솔루션이 개발되었습니다. DNSSEC(DNS 보안 확장)는 DNS에 인증 기능을 제공하며, DNS 정보가 변조되지 않도록 보호합니다. DNS over HTTPS는 DNS 요청과 응답을 HTTPS 프로토콜로 암호화하여 네트워크 중의 공격자가 DNS 정보를 엿볼 수 없도록 보호합니다.

 

# 요약

도메인 이름 시스템 (DNS)는 인터넷의 핵심 구성 요소로, IP 주소 대신 쉽게 기억할 수 있는 도메인 이름을 사용하여 웹 사이트에 액세스 할 수 있게 합니다. DNS는 계층 구조로 구성되어 있으며, 계층 구조의 최상위에는 루트 서버가 있습니다. DNS 레코드는 A, MX, CNAME 등을 사용하여 도메인 이름과 IP 주소를 매핑하고 이메일과 별칭 설정을 구성합니다.

그리고 DNS는 악의적 공격의 대상이 되며, DNS 스푸핑과 캐시 오염과 같은 보안 위협이 있습니다. 이러한 위협들에 대비하기 위해 DNSSEC과 DNS over HTTPS라는 보안 솔루션이 개발되었습니다.

앞으로 살펴볼 요소들에 비해 DNS 서버는 ISP(인터넷 서비스 제공자: 흔히 생각하시는 통신사죠)나 사내 인프라실 같은 곳에 계신가 아니라면 직접 다룰일은 거의 없지만, 서버 발주/클라우드 인스턴스 생성등을 하다 보면 관련된 용어들을 접할 수 있으니 알아두시면 좋을 것 같습니다.

 

# (추가) DNS 분산 시스템

 DNS가 인터넷의 핵심 구성요소인 것을 이해했다면, 여기가 단일 병목 지점(single point of failure)이 되어선 안된다는 걸 알 수 있습니다. 

Scalability, reliability 등을 보장하기 위해  DNS 구조도 root-level 13개의 인스턴스를 1,000여 개의 레플리케이션을 세계 곳곳에 가지고 있습니다. 캐싱뿐만 아니라 서버 레플리케이션을 가지며, 대부분의 클라이언트가 DNS를 UDP를 이용해 호출하지만, 안정성이나 보안측면에서 TCP 커넥션을 이용하기도 합니다. 앞서 살펴본 HTTPS처럼 더 상위 레이어를 통할 경우 안정성과 응답속도를 교환하는 구조가 되는 것이죠. (주로 메시지의 크기나 데이터 유형에 따라 프로토콜을 선택하게 됩니다. 주고받는 데이터 사이즈가 커질수록 안정성이 중요해지니까요.)

## Consistency

Consistency에 대해선 전에 살짝 다뤘었는데요, DNS는 eventual consistency를 지향합니다. 즉 빠른 응답속도를 위해 실시간성을 어느 정도 포기하고, 레플리카 노드 간에 업데이트가 모두 이루어지는 데에는 대게 수 초에서 3일 정도 까지도 걸린다고 합니다. 업데이트의 규모나 DNS 트리 구조상 어느 구역이 업데이트되느냐에 따라 소요 시간이 길어질 수 도 있는 것이죠. (주소 변경이 발생한다 해도 DNS는 항상 available 해야 하니까요.)

캐싱 또한 응답 속도를 높여주는 요소지만, consistency를 깨뜨리는 역할을 하기도 합니다. (도메인이나 IP정보가 바뀌었는데 오래된 캐시가 남아있어서 정상적으로 주소를 찾지 못하는 경우) 이런 문제를 최소화하기 위해 각 캐시 레코드에는 expiration time을 지정합니다.(Time to live : TTL) TTL은 그 역할을 제대로 수행하기 위해 대게 작은 값으로 설정합니다. (작게는 2분에서 길게는 10분 이내 정도로)

 

## 실습

터미널에서 몇 가지 커맨드로 DNS의 동작을 살펴볼 수 있습니다. nslookup 커맨드와 dig 커맨드입니다.
터미널에 아래 두 커맨드를 복사해 넣고, 결과 값을 살펴봅니다.

1. nslookup www.google.com 
2. dig www.google.com

❯ nslookup www.google.com
Server:		168.126.63.1
Address:	168.126.63.1#53

Non-authoritative answer:
Name:	www.google.com
Address: 142.250.196.100

- Non-authoritative answer를 보면, 구글 서버가 아니라 어딘가 중간 단계에서 응답이 내려온 것이라는 의미입니다. (캐시 되어있다는 뜻이죠) 중간에 학교, 회사의 DNS resolver 거나, ISP 네임서버 같은 곳이겠죠?

❯ dig www.google.com

; <<>> DiG 9.10.6 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38427
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.google.com.			IN	A

;; ANSWER SECTION:
www.google.com.		33	IN	A	142.251.42.196

;; Query time: 6 msec
;; SERVER: 168.126.63.1#53(168.126.63.1)
;; WHEN: Sun Jan 22 11:40:30 KST 2023
;; MSG SIZE  rcvd: 59

- dig 커맨드로 응답 시간이 10 msec 인 것을 알 수 있습니다. 이 응답 속도는 매번 달라지겠죠?
- ANSWER SECTION의 33 은 DNS resolver에 해당 레코드가 몇 초 동안이나 캐싱되어있었는지를 나타냅니다.

 

## 생각거리

DNS 가 어떤 웹사이트나 서비스의 IP 주소를 알려주는 시스템이라면, 우리가 사용하는 컴퓨터는 DNS resolver의 IP 주소(root level)는 어떻게 알 수 있을까요?

<정답은 더 보기를 펼쳐 보세요>

OS 내에 (리눅스의 경우 /etc/resolv.conf ) DNS resolver의 IP 주소가 저장되어 있습니다. DNS resolver는 자주 바뀌는 일이 없기 때문에 OS에 13개의 root-level 서버의 주소가 내장되어 있는 셈이죠.