DNS는 어떻게 도메인을 IP 주소로 바꿀까?

인터넷을 사용할 때 우리는 보통 IP 주소를 직접 입력하지 않는다.

예를 들어 웹사이트에 접속할 때

www.example.com

처럼 사람이 읽기 편한 도메인 이름을 입력한다.

그런데 컴퓨터와 네트워크는 결국 IP 주소를 이용해서 통신한다.

예를 들어 어떤 서버의 주소가

203.0.113.10

이라고 해보자.

사용자가 브라우저에 www.example.com을 입력했다고 해서 컴퓨터가 그 문자열을 그대로 들고 서버와 통신할 수 있는 것은 아니다.

어딘가에서

www.example.com
        ↓
203.0.113.10

이라는 정보를 찾아야 한다.

이 역할을 하는 것이 바로 DNS(Domain Name System)​다.

그렇다면 DNS는 단순히 도메인 이름을 입력하면 바로 IP 주소를 알려주는 것일까?

실제로는 여러 단계의 DNS 서버가 서로 역할을 나누어 동작한다.

이번 글에서는 브라우저에 도메인을 입력했을 때 DNS가 어떻게 IP 주소를 찾아가는지 순서대로 정리해보자.

---

DNS가 필요한 이유

컴퓨터 입장에서 IP 주소는 통신하기 좋은 주소지만 사람이 기억하기에는 불편하다.

예를 들어 다음과 같은 주소를 외운다고 생각해보자.

142.250.xxx.xxx

웹사이트가 많아질수록 이런 숫자 주소를 모두 기억하는 것은 현실적으로 어렵다.

그래서 사람이 기억하기 쉬운 이름을 사용한다.

google.com
naver.com
github.com

DNS는 이런 이름과 IP 주소 사이를 연결해준다.

사람
  ↓
www.example.com
  ↓
DNS
  ↓
203.0.113.10
  ↓
서버 접속

전화번호부에 이름과 전화번호가 연결되어 있는 것과 비슷한 역할이라고 생각하면 이해하기 쉽다.

다만 DNS는 단순한 하나의 전화번호부가 아니다.

인터넷 전체의 도메인 정보를 하나의 서버가 가지고 있는 것이 아니라 여러 DNS 서버가 계층적으로 나누어 관리한다.

---

DNS는 하나의 서버가 아니다

DNS를 처음 공부할 때 가장 헷갈리는 부분 중 하나가 이것이다.

DNS 서버라고 해서 전 세계에 하나의 DNS 서버가 존재하는 것은 아니다.

DNS는 여러 종류의 서버가 계층적으로 연결되어 있다.

대표적으로 다음 네 가지를 이해하면 된다.

① 재귀 DNS 서버(Recursive DNS Resolver)
② 루트 DNS 서버(Root DNS Server)
③ TLD DNS 서버
④ 권한 있는 DNS 서버(Authoritative DNS Server)

각각의 역할이 조금씩 다르다.

전체적인 구조를 먼저 보면 다음과 같다.

사용자 PC
   │
   │ DNS Query
   ▼
재귀 DNS 서버
   │
   ▼
Root DNS
   │
   ▼
TLD DNS
   │
   ▼
Authoritative DNS
   │
   ▼
IP 주소

이제 각각 어떤 역할을 하는지 살펴보자.

---

1. 사용자가 도메인을 입력한다

먼저 사용자가 브라우저에 도메인을 입력한다.

예를 들어

www.example.com

이라고 해보자.

브라우저는 이 문자열만 가지고 서버에 바로 접속하는 것이 아니다.

먼저 해당 도메인의 IP 주소가 무엇인지 확인해야 한다.

일반적인 흐름에서는 운영체제에 설정된 DNS 서버, 즉 재귀 DNS 서버(Recursive Resolver)​에 질의를 보내게 된다.

PC
 │
 │ "www.example.com의 IP가 뭐야?"
 ▼
Recursive DNS Resolver

여기서 중요한 점은 사용자의 컴퓨터가 항상 루트 DNS부터 직접 찾아가는 것은 아니라는 것이다.

보통 사용자는 재귀 DNS 서버 하나에 질의를 보내고, 재귀 DNS 서버가 필요한 DNS 서버들을 대신 찾아간다.

---

2. 재귀 DNS 서버는 먼저 정보를 확인한다

재귀 DNS 서버는 사용자를 대신해서 DNS 정보를 찾아주는 역할을 한다.

예를 들어 PC가

www.example.com

의 IP 주소를 물어봤다고 해보자.

재귀 DNS 서버는 자신이 이미 해당 정보를 가지고 있는지 확인한다.

이전에 같은 도메인을 조회한 기록이 있고 TTL이 아직 남아 있다면 바로 응답할 수 있다.

Client
  │
  │ www.example.com?
  ▼
Recursive Resolver
  │
  │ 캐시에 정보가 있음
  ▼
IP 주소 반환

이 경우에는 뒤에 있는 루트 DNS나 TLD DNS까지 갈 필요가 없다.

다만 이번 글에서는 캐시에 정보가 없다고 가정하고 실제 DNS 조회가 어떻게 진행되는지 살펴보자.

---

3. Root DNS 서버에 질문한다

재귀 DNS 서버에 해당 도메인 정보가 없다면 다음 단계로 넘어간다.

가장 먼저 Root DNS 서버를 찾아간다.

여기서 중요한 점이 있다.

Root DNS 서버가

www.example.com → 203.0.113.10

같은 최종 IP 주소를 알려주는 것은 아니다.

Root DNS 서버는 어떤 TLD 서버에게 물어봐야 하는지 알려주는 역할을 한다.

도메인 이름을 보면

www.example.com
             └── .com

가장 오른쪽에 .com이 있다.

이 .com을 담당하는 DNS 서버를 TLD DNS 서버라고 한다.

따라서 Root DNS 서버는 대략 이런 식으로 답한다.

"www.example.com의 주소를 알고 싶어?"

"그 도메인은 .com이니까
 .com TLD DNS 서버에게 물어봐."

즉,

Recursive Resolver
        │
        │ www.example.com?
        ▼
Root DNS
        │
        │ .com을 담당하는 서버 알려줌
        ▼
.com TLD DNS

이라는 흐름이 만들어진다.

---

4. TLD DNS 서버로 이동한다

이번에는 재귀 DNS 서버가 .com TLD DNS 서버에 질문한다.

"www.example.com을 담당하는 서버가 어디야?"

여기서 TLD는 Top-Level Domain의 약자다.

대표적으로

.com
.org
.net
.kr
.jp

등이 있다.

TLD DNS 서버 역시 일반적으로 최종 IP 주소를 직접 알려주는 것이 아니라 해당 도메인을 실제로 관리하는 권한 있는 DNS 서버(Authoritative DNS Server) 정보를 알려준다.

예를 들어 개념적으로 다음과 같은 답을 받을 수 있다.

example.com의 DNS 정보는
ns1.example-dns.com에서 관리하고 있어.

그러면 재귀 DNS 서버는 해당 Authoritative DNS 서버로 다시 질문한다.

Recursive Resolver
        │
        ▼
Root DNS
        │
        ▼
.com TLD DNS
        │
        │ example.com 담당 DNS 알려줌
        ▼
Authoritative DNS

---

5. Authoritative DNS 서버가 최종 정보를 가지고 있다

이제 마지막 단계다.

Authoritative DNS Server는 특정 도메인의 DNS 정보를 실제로 관리하는 서버다.

재귀 DNS 서버가 여기에서 질문한다.

"www.example.com의 A 레코드가 뭐야?"

그러면 Authoritative DNS 서버가 등록된 DNS 정보를 바탕으로 응답한다.

예를 들어

www.example.com
        ↓
203.0.113.10

이라는 정보가 등록되어 있다면 이 IP 주소를 응답한다.

전체 과정은 다음처럼 이어진다.

사용자
  │
  │ www.example.com
  ▼
Recursive DNS Resolver
  │
  │ ① Root에 질문
  ▼
Root DNS
  │
  │ ② .com 서버 안내
  ▼
.com TLD DNS
  │
  │ ③ example.com 담당 서버 안내
  ▼
Authoritative DNS
  │
  │ ④ IP 주소 응답
  ▼
Recursive Resolver
  │
  │ ⑤ 사용자에게 IP 전달
  ▼
사용자

처음 보면 상당히 복잡해 보이지만 역할을 나누면 생각보다 단순하다.

Root
→ 어느 TLD에게 물어볼지 알려줌

TLD
→ 어느 도메인 관리 서버에게 물어볼지 알려줌

Authoritative
→ 실제 DNS 정보를 가지고 있음

Recursive Resolver
→ 이 과정을 대신 수행해서 사용자에게 결과를 알려줌

---

DNS에는 여러 종류의 레코드가 있다

DNS가 항상 도메인 이름을 IPv4 주소로만 바꾸는 것은 아니다.

DNS 서버에는 여러 종류의 Resource Record가 존재한다.

대표적인 것들을 보면 다음과 같다.

레코드	역할
A	도메인을 IPv4 주소와 연결
AAAA	도메인을 IPv6 주소와 연결
CNAME	다른 도메인 이름을 가리킴
MX	메일 서버 정보
NS	해당 도메인을 담당하는 DNS 서버
TXT	텍스트 형태의 정보 저장

우리가 흔히 말하는

도메인 → IP 주소

는 주로 A 레코드 조회를 의미한다.

IPv6 주소를 확인할 때는 AAAA 레코드를 사용한다.

예를 들어

www.example.com
        │
        ├── A
        │    └── IPv4
        │
        └── AAAA
             └── IPv6

처럼 하나의 도메인이 여러 DNS 레코드를 가질 수도 있다.

---

DNS 조회가 끝나면 그다음에는?

재귀 DNS 서버가 최종 IP 주소를 알아냈다면 이제 사용자 컴퓨터에 결과를 알려준다.

예를 들어

www.example.com
        ↓
203.0.113.10

이라는 결과를 받았다고 해보자.

그러면 브라우저는 이 IP 주소를 이용해 실제 서버와 통신을 시작한다.

앞에서 공부했던 내용과 연결하면 흐름이 이렇게 된다.

도메인 입력
   ↓
DNS 조회
   ↓
IP 주소 확인
   ↓
TCP 연결
   ↓
TLS 연결(HTTPS라면)
   ↓
HTTP 요청
   ↓
서버 응답

즉 DNS는 웹 통신 전체 과정의 가장 앞부분에서 “어느 서버로 가야 하는가?”를 찾아주는 역할​을 한다.

이후에는 TCP, TLS, HTTP 등의 과정이 이어진다.

---

그런데 DNS 조회를 매번 이렇게 하면 너무 느리지 않을까?

여기서 DNS 캐시가 등장한다.

매번

PC
 ↓
Recursive DNS
 ↓
Root
 ↓
TLD
 ↓
Authoritative

과정을 반복한다면 불필요한 시간이 계속 발생할 것이다.

그래서 DNS에서는 조회 결과를 일정 시간 동안 저장해두는 캐싱을 사용한다.

DNS 응답에는 TTL(Time To Live)​이라는 값이 존재한다.

예를 들어 어떤 DNS 레코드의 TTL이

300초

라고 되어 있다면 재귀 DNS 서버는 해당 결과를 일정 시간 동안 캐시에 보관하고 다시 같은 도메인을 요청받았을 때 캐시된 결과를 사용할 수 있다.

첫 번째 요청
Client
  ↓
Recursive DNS
  ↓
Root → TLD → Authoritative
  ↓
IP
  ↓
캐시에 저장

두 번째 요청
Client
  ↓
Recursive DNS
  ↓
캐시된 IP 바로 응답

이 때문에 실제 인터넷에서 발생하는 DNS 질의가 항상 처음부터 끝까지 모든 계층을 거치는 것은 아니다.

DNS 캐싱에 대해서는 앞에서 따로 다뤘던 내용과도 연결되는 부분이다.

---

DNS는 항상 UDP를 사용할까?

DNS를 공부하다 보면 “DNS는 UDP 53번 포트를 사용한다”​라는 설명을 많이 보게 된다.

기본적인 DNS 질의에서는 UDP 53번 포트를 사용하는 경우가 일반적이다.

Client
   │
   │ UDP 53
   ▼
DNS Server

하지만 DNS가 무조건 UDP만 사용하는 것은 아니다.

응답이 너무 크거나 특정 상황에서는 TCP 53번을 사용할 수 있다.

또한 DNS를 암호화해서 전달하는 방식도 있다.

대표적으로

DNS over TLS  → TCP 853
DNS over HTTPS → HTTPS 443

등이 있다.

따라서

“DNS = UDP 53”

이라고만 외우기보다는

“일반적인 DNS 질의는 UDP 53을 많이 사용하지만 상황에 따라 TCP나 암호화된 DNS 방식도 사용한다.”

정도로 이해하는 것이 좋다.

---

실제로는 어떤 순서로 동작할까?

지금까지 내용을 하나로 합치면 다음과 같다.

① 브라우저에 www.example.com 입력
                ↓
② 로컬에서 DNS 정보 확인
                ↓
③ Recursive DNS Resolver에 질의
                ↓
④ 캐시에 없으면 Root DNS에 질의
                ↓
⑤ .com TLD DNS 서버 확인
                ↓
⑥ example.com의 Authoritative DNS 확인
                ↓
⑦ A/AAAA 레코드에서 IP 주소 확인
                ↓
⑧ Recursive Resolver가 결과를 캐시
                ↓
⑨ 사용자에게 IP 주소 전달
                ↓
⑩ 브라우저가 해당 IP로 접속

여기서 ②의 로컬 캐시나 ③ 이후의 재귀 DNS 캐시 등에 이미 정보가 있다면 중간 과정은 생략될 수 있다.

그래서 사용자가 체감하기에는

www.example.com
        ↓
IP 주소

가 거의 즉시 이루어지는 것처럼 보인다.

실제로는 여러 계층이 협력하고 있고, 캐시 덕분에 대부분의 요청은 훨씬 짧은 경로로 처리될 수 있는 것이다.

---

마무리

DNS는 단순히 “도메인을 IP로 바꿔주는 서버”라고만 생각하면 조금 아쉽다.

정확하게는 도메인 이름에 대한 정보를 계층적으로 관리하고 질의할 수 있도록 만들어진 시스템이라고 이해하는 것이 좋다.

특히 이번 글에서 기억할 핵심은 다음과 같다.

사용자
 ↓
Recursive DNS Resolver
 ↓
Root DNS
 ↓
TLD DNS
 ↓
Authoritative DNS
 ↓
IP 주소

각 서버의 역할도 구분해두면 좋다.

Recursive Resolver
→ 사용자를 대신해서 DNS 조회를 수행

Root DNS
→ TLD 서버를 안내

TLD DNS
→ 해당 도메인을 담당하는 DNS 서버를 안내

Authoritative DNS
→ 실제 도메인의 DNS 레코드를 관리

그리고 최종적으로 IP 주소를 알아낸 다음에야 우리가 앞에서 공부했던 TCP 연결이나 HTTP 통신으로 넘어갈 수 있다.

그래서 웹 브라우저에 주소 하나를 입력하는 것만 해도 실제 내부에서는

도메인 이름
 → DNS
 → IP 주소
 → TCP
 → TLS
 → HTTP
 → 서버

라는 여러 과정이 이어진다.

다음에는 여기서 한 단계 더 들어가서 DNS 질의(Query)가 실제로 어떤 방식으로 오가는지, 재귀 질의와 반복 질의는 무엇이 다른지, 그리고 DNS가 UDP 53번을 사용하는 이유까지 살펴보면 DNS 동작 방식이 훨씬 명확해진다.