DNS 질의가 이루어지는 과정 쉽게 이해하기

위치:

네트워크 관련 정리

9월 6, 2026
0
480 words

앞에서 DNS가 도메인 이름을 IP 주소로 바꿔주는 과정에 대해 알아봤다.

우리가 브라우저에

www.example.com

을 입력하면 DNS를 통해 해당 도메인의 IP 주소를 확인하고, 그 결과를 이용해 실제 서버와 통신하게 된다.

그런데 여기서 한 가지 궁금한 점이 생긴다.

DNS는 실제로 어떤 방식으로 질문하고 답을 받는 걸까?

DNS에서는 이 과정을 DNS Query(질의)라고 한다.

예를 들어 컴퓨터가 DNS 서버에게

www.example.com의 IPv4 주소가 뭐야?

라고 질문하면 DNS 서버는 그에 대한 응답을 보내준다.

그런데 DNS는 단순히 컴퓨터와 DNS 서버가 한 번 질문하고 한 번 답하는 구조만 있는 것은 아니다.

DNS 서버끼리 다시 질문을 주고받기도 하고, 경우에 따라 UDP를 사용하다가 TCP로 전환하기도 한다.

이번 글에서는 DNS Query가 실제로 어떤 흐름으로 진행되는지, 그리고 재귀 질의(Recursive Query)와 반복 질의(Iterative Query)가 무엇이 다른지 중심으로 살펴보자.

DNS Query란 무엇일까?

DNS Query는 말 그대로 DNS 서버에게 정보를 요청하는 것이다.

예를 들어 사용자가

www.example.com

에 접속하려고 한다고 해보자.

컴퓨터는 DNS 서버에게 다음과 같은 정보를 요청한다.

이름: www.example.com
종류: A

여기서 A는 IPv4 주소를 요청한다는 의미다.

그러면 DNS 서버는

www.example.com
        ↓
203.0.113.10

과 같은 결과를 응답한다.

즉 가장 단순한 형태로 보면

Client
   │
   │ DNS Query
   │ "www.example.com의 A 레코드?"
   ▼
DNS Server
   │
   │ DNS Response
   │ "203.0.113.10"
   ▼
Client

이것이 DNS 질의의 기본 구조다.

하지만 실제 인터넷에서는 이 과정이 조금 더 복잡하다.

DNS Query에는 어떤 정보가 들어갈까?

DNS 요청은 단순한 문자열 하나만 보내는 것이 아니다.

DNS 메시지에는 여러 가지 정보가 들어간다.

대표적으로 다음과 같은 항목을 생각할 수 있다.

DNS Header
DNS Question
DNS Answer
Authority
Additional

특히 질문을 보낼 때 중요한 것은 어떤 이름을 어떤 종류로 조회할 것인지다.

예를 들어

Name: www.example.com
Type: A
Class: IN

과 같은 정보가 들어갈 수 있다.

여기서 IN은 인터넷에서 사용하는 일반적인 DNS 클래스다.

응답에는 실제 IP 주소가 포함될 수 있다.

Question
www.example.com / A

Answer
www.example.com / A / 203.0.113.10

DNS 패킷을 분석할 때 Wireshark를 사용하면 이런 정보를 직접 확인할 수 있다.

모든 DNS 서버에게 똑같이 질문하는 것은 아니다

DNS 질의를 이해할 때 가장 중요한 부분 중 하나가 재귀 질의와 반복 질의의 차이다.

두 개념의 차이를 먼저 간단하게 보면 다음과 같다.

구분	재귀 질의	반복 질의
영어	Recursive Query	Iterative Query
요청하는 쪽	보통 클라이언트 → 재귀 DNS	재귀 DNS → 다른 DNS 서버
원하는 것	최종 답변	알고 있는 정보 또는 다음 서버 안내
조회 과정	서버가 대신 수행	질의자가 다음 서버를 직접 찾아감

처음 보면 이름 때문에 상당히 헷갈릴 수 있다.

핵심은 이것만 기억하면 된다.

재귀 질의 = “네가 알아서 끝까지 찾아서 최종 답을 줘.”

반복 질의 = “네가 알고 있는 데까지 알려줘. 다음에는 내가 물어볼게.”

재귀 질의는 어떤 방식일까?

사용자의 컴퓨터가 DNS 서버에 질문하는 상황을 생각해보자.

Client
   │
   │ "www.example.com의 IP 알려줘."
   ▼
Recursive DNS Resolver

클라이언트 입장에서는 최종 IP 주소가 필요하다.

그래서 재귀 DNS 서버에게 사실상

“내 대신 알아서 찾아서 최종 결과를 알려줘.”

라는 형태로 요청한다.

재귀 DNS 서버는 필요한 경우 다른 DNS 서버들에게 계속 질문해서 최종 결과를 알아낸다.

Client
   │
   │ Recursive Query
   ▼
Recursive Resolver
   │
   ├──→ Root DNS
   │
   ├──→ .com TLD DNS
   │
   └──→ Authoritative DNS
              │
              ▼
            IP 주소

그리고 최종적으로 결과를 다시 클라이언트에게 전달한다.

Authoritative DNS
       ↓
Recursive Resolver
       ↓
Client

사용자 입장에서는 중간의 복잡한 DNS 서버들을 직접 신경 쓸 필요가 없는 것이다.

반복 질의는 어떻게 다를까?

반복 질의는 조금 다르다.

재귀 DNS 서버가 Root DNS 서버에게 질문한다고 해보자.

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

Root DNS 서버가 최종 IP 주소를 알고 있지 않다면 직접 모든 과정을 대신 수행하지 않는다.

대신 다음과 같이 알려준다.

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

그러면 재귀 DNS 서버가 다시 .com TLD DNS 서버에게 질문한다.

Recursive Resolver
        │
        ▼
.com TLD DNS
        │
        │ "example.com 담당 서버는 여기야."
        ▼
Authoritative DNS

이것이 반복 질의의 핵심이다.

질문을 받은 서버가 최종 답을 찾아주는 것이 아니라, 자신이 알고 있는 정보와 다음에 물어볼 곳을 알려준다.

실제 DNS 조회 과정을 연결해보자

이제 전체 과정을 하나로 연결해보자.

사용자가 브라우저에

www.example.com

을 입력했다고 가정한다.

1단계: 클라이언트가 DNS 서버에 질문

Client
   │
   │ "www.example.com의 A 레코드?"
   ▼
Recursive Resolver

이때 일반적으로 사용자의 컴퓨터가 사용하는 DNS 서버는 ISP나 기업 네트워크에서 제공하는 DNS 서버일 수도 있고, 사용자가 별도로 설정한 공개 DNS 서버일 수도 있다.

2단계: 재귀 DNS 서버가 Root DNS에 질문

재귀 DNS 서버에 캐시된 정보가 없다면 Root DNS 서버에 질문한다.

Recursive Resolver
       │
       │ www.example.com / A
       ▼
Root DNS

Root DNS는 .com을 담당하는 TLD DNS 서버 정보를 알려준다.

Root DNS
   ↓
".com TLD 서버에게 물어봐."

3단계: TLD DNS에 질문

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

Recursive Resolver
       │
       │ example.com?
       ▼
.com TLD DNS

TLD DNS는 example.com을 관리하는 Authoritative DNS 서버 정보를 알려준다.

.com TLD
   ↓
"example.com의 DNS 정보는
 이 Authoritative DNS가 가지고 있어."

4단계: Authoritative DNS에 질문

마지막으로 재귀 DNS 서버가 해당 Authoritative DNS 서버에 질문한다.

Recursive Resolver
       │
       │ www.example.com / A
       ▼
Authoritative DNS

이 서버가 실제 DNS 레코드를 가지고 있다.

예를 들어 다음과 같은 정보가 등록되어 있다고 해보자.

www.example.com
A
203.0.113.10

그러면 이 IP 주소를 응답한다.

5단계: 최종 결과를 클라이언트에게 전달

재귀 DNS 서버는 최종 결과를 받아서 사용자에게 전달한다.

Authoritative DNS
       │
       │ 203.0.113.10
       ▼
Recursive Resolver
       │
       │ 203.0.113.10
       ▼
Client

이제 컴퓨터는

www.example.com
        ↓
203.0.113.10

이라는 정보를 알게 된다.

그다음부터는 DNS가 아니라 해당 IP 주소를 이용한 실제 네트워크 통신이 시작된다.

DNS는 왜 UDP 53번을 많이 사용할까?

DNS를 공부할 때 자주 나오는 것이 UDP 53번 포트다.

일반적인 DNS 질의는 UDP를 이용하는 경우가 많다.

Client
   │
   │ UDP
   │ Port 53
   ▼
DNS Server

UDP를 사용하는 이유 중 하나는 DNS의 일반적인 질의가 비교적 짧고 간단하기 때문이다.

TCP처럼 연결을 먼저 설정하지 않아도 바로 요청과 응답을 주고받을 수 있다.

DNS는 아주 많은 질의가 발생하는 서비스이기 때문에 이런 특성이 유리하다.

다만 DNS = 무조건 UDP라고 생각하면 안 된다.

특정 상황에서는 TCP를 사용할 수 있다.

DNS에서 TCP를 사용하는 경우도 있다

DNS는 필요한 경우 TCP 53번을 사용할 수 있다.

예를 들어 DNS 응답이 UDP로 처리하기에 적절하지 않은 경우 TCP를 사용할 수 있다.

전통적인 DNS에서는 UDP 응답이 너무 커서 완전히 전달되지 못하는 경우 TC(Truncated) 플래그가 표시되고 TCP로 다시 질의하는 방식이 사용될 수 있다.

또한 DNS 서버 간의 Zone Transfer 같은 작업에서도 TCP가 사용된다.

따라서 기본적인 관계는 다음처럼 이해하면 된다.

일반적인 DNS Query
        ↓
UDP 53

특정 상황
        ↓
TCP 53

그리고 현대적인 환경에서는 DNS 자체를 암호화하는 방식도 있다.

DNS over TLS
→ TCP 853

DNS over HTTPS
→ HTTPS 443

DNS Query에도 ID가 있다

DNS 패킷을 조금 더 자세히 보면 Transaction ID라는 값도 볼 수 있다.

왜 이런 값이 필요할까?

하나의 컴퓨터가 DNS 요청을 하나만 보내는 것은 아니기 때문이다.

예를 들어 동시에 여러 도메인의 정보를 요청할 수 있다.

Query ① → www.example.com
Query ② → api.example.com
Query ③ → mail.example.com

각 요청을 구분할 수 있어야 어떤 응답이 어떤 요청에 해당하는지 확인하기 쉽다.

그래서 DNS 메시지에는 질의와 응답을 대응시키기 위한 식별 정보가 포함된다.

Wireshark로 DNS 패킷을 보면 이런 Transaction ID를 직접 확인할 수 있다.

DNS Query는 한 번만 발생하지 않을 수도 있다

웹사이트 하나를 접속한다고 해서 DNS 질의가 반드시 한 번만 발생하는 것도 아니다.

웹페이지가 여러 서버의 리소스를 불러온다면 각각 다른 도메인에 대한 DNS 조회가 필요할 수 있다.

예를 들어

www.example.com
api.example.com
image.examplecdn.com
font.examplecdn.com

처럼 여러 도메인이 사용될 수 있다.

그러면 각각의 이름을 확인하기 위한 DNS 조회가 발생할 수 있다.

브라우저
  │
  ├──→ DNS → www.example.com
  │
  ├──→ DNS → api.example.com
  │
  ├──→ DNS → image.examplecdn.com
  │
  └──→ DNS → font.examplecdn.com

물론 DNS 캐시가 존재하면 모든 요청이 실제 DNS 서버까지 전달되는 것은 아니다.

DNS 캐시는 왜 중요한가?

앞에서 설명한 과정을 매번 반복한다면 상당히 비효율적이다.

Client
 ↓
Recursive
 ↓
Root
 ↓
TLD
 ↓
Authoritative

웹사이트를 방문할 때마다 이 과정을 반복하면 불필요한 DNS 트래픽과 지연이 발생한다.

그래서 DNS에서는 조회 결과를 캐시에 저장한다.

예를 들어 재귀 DNS 서버가

www.example.com
→ 203.0.113.10

이라는 결과를 얻었다면 TTL 동안 이 결과를 저장할 수 있다.

다음 사용자가 같은 도메인을 요청하면

Client
   ↓
Recursive Resolver
   ↓
캐시 확인
   ↓
IP 주소 바로 응답

할 수 있다.

이렇게 하면 Root DNS나 TLD DNS까지 다시 찾아갈 필요가 없다.

DNS 캐시는 속도를 높이는 동시에 DNS 서버 사이에서 발생하는 불필요한 질의를 줄이는 역할도 한다.

DNS Query 과정을 그림으로 정리하면

지금까지의 내용을 하나의 흐름으로 정리하면 다음과 같다.

[사용자 PC]
     │
     │ ① Recursive Query
     ▼
[Recursive DNS Resolver]
     │
     │ ② Iterative Query
     ▼
[Root DNS]
     │
     │ ③ .com TLD 안내
     ▼
[.com TLD DNS]
     │
     │ ④ Authoritative DNS 안내
     ▼
[Authoritative DNS]
     │
     │ ⑤ 실제 IP 응답
     ▼
[Recursive DNS Resolver]
     │
     │ ⑥ 최종 IP 응답
     ▼
[사용자 PC]

여기서 핵심은 사용자 PC와 재귀 DNS 서버 사이의 역할과 DNS 서버들 사이의 역할이 다르다는 것이다.

Client → Recursive Resolver
"최종 결과를 찾아줘."

Recursive Resolver → Root/TLD/Authoritative
"이 도메인에 대해 알고 있는 정보를 알려줘."

이 차이를 이해하면 재귀 질의와 반복 질의가 훨씬 쉽게 구분된다.

직접 DNS 질의를 확인해볼 수도 있다

리눅스나 macOS에서는 dig 같은 명령어를 이용해서 DNS 질의를 직접 확인할 수 있다.

dig example.com

또는 특정 DNS 서버에 질의할 수도 있다.

dig @8.8.8.8 example.com

Windows에서는 다음과 같은 명령어를 사용할 수 있다.

nslookup example.com

실행하면 DNS 서버와 질의한 도메인, 응답받은 IP 주소 등을 확인할 수 있다.

이런 도구를 한번 직접 사용해보면 DNS가 단순히 “도메인 → IP 변환”만 하는 것이 아니라 실제로 질의와 응답이라는 과정을 거쳐 동작한다는 것을 이해하기 좋다.

마무리

DNS Query는 쉽게 말하면 “이 도메인에 대한 정보를 알려달라”고 DNS 서버에 요청하는 과정이다.

하지만 실제 DNS 시스템에서는 하나의 서버가 모든 정보를 가지고 있는 것이 아니다.

Client
 ↓
Recursive Resolver
 ↓
Root DNS
 ↓
TLD DNS
 ↓
Authoritative DNS

이런 계층적인 구조를 통해 필요한 정보를 찾아간다.

여기서 가장 중요한 개념은 두 가지다.

재귀 질의

"네가 대신 끝까지 찾아서 최종 결과를 알려줘."

반복 질의

"네가 알고 있는 정보와
다음에 물어볼 서버를 알려줘."

그리고 일반적인 DNS 질의는 UDP 53번을 사용하는 경우가 많지만, 특정 상황에서는 TCP 53번을 사용하거나 DNS over TLS, DNS over HTTPS처럼 암호화된 방식도 사용할 수 있다.

결국 우리가 브라우저에 도메인 하나를 입력하는 순간에도 내부에서는 여러 DNS 서버가 질의와 응답을 주고받고 있으며, 최종적으로 IP 주소를 알아낸 뒤에야 실제 서버와의 통신이 시작된다.

앞에서 배운 내용을 연결해보면 흐름이 조금씩 완성된다.

도메인 입력
   ↓
DNS Query
   ↓
IP 주소 확인
   ↓
TCP 연결
   ↓
TLS 연결
   ↓
HTTP 요청
   ↓
HTTP 응답

다음 글에서는 이제 DNS를 넘어 HTTP 요청과 응답이 실제로 어떤 형태로 오가는지 알아보면, 우리가 웹사이트에 접속할 때 일어나는 과정이 한층 더 구체적으로 보이기 시작한다.

DNS Query란 무엇일까?

DNS Query에는 어떤 정보가 들어갈까?

모든 DNS 서버에게 똑같이 질문하는 것은 아니다

재귀 질의는 어떤 방식일까?

반복 질의는 어떻게 다를까?

실제 DNS 조회 과정을 연결해보자

1단계: 클라이언트가 DNS 서버에 질문

2단계: 재귀 DNS 서버가 Root DNS에 질문

3단계: TLD DNS에 질문

4단계: Authoritative DNS에 질문

5단계: 최종 결과를 클라이언트에게 전달

DNS는 왜 UDP 53번을 많이 사용할까?

DNS에서 TCP를 사용하는 경우도 있다

DNS Query에도 ID가 있다

DNS Query는 한 번만 발생하지 않을 수도 있다

DNS 캐시는 왜 중요한가?

DNS Query 과정을 그림으로 정리하면

직접 DNS 질의를 확인해볼 수도 있다

마무리

답글 남기기 응답 취소

글쓴이

웹 브라우저에 주소를 입력하면 일어나는 일

소켓이란 무엇일까? 프로그램과 네트워크를 연결하는 통로

쿠키와 세션은 어떻게 다를까?

웹 브라우저에 주소를 입력하면 일어나는 일

소켓이란 무엇일까? 프로그램과 네트워크를 연결하는 통로

쿠키와 세션은 어떻게 다를까?

DNS Query란 무엇일까?

DNS Query에는 어떤 정보가 들어갈까?

모든 DNS 서버에게 똑같이 질문하는 것은 아니다

재귀 질의는 어떤 방식일까?

반복 질의는 어떻게 다를까?

실제 DNS 조회 과정을 연결해보자

1단계: 클라이언트가 DNS 서버에 질문

2단계: 재귀 DNS 서버가 Root DNS에 질문

3단계: TLD DNS에 질문

4단계: Authoritative DNS에 질문

5단계: 최종 결과를 클라이언트에게 전달

DNS는 왜 UDP 53번을 많이 사용할까?

DNS에서 TCP를 사용하는 경우도 있다

DNS Query에도 ID가 있다

DNS Query는 한 번만 발생하지 않을 수도 있다

DNS 캐시는 왜 중요한가?

DNS Query 과정을 그림으로 정리하면

직접 DNS 질의를 확인해볼 수도 있다

마무리

답글 남기기 응답 취소

글쓴이

관련 게시물