DNS와 TCP 통신 흐름을 시각화하며 이해하기 – nslookup, tracert, Wireshark 실습 기록

학습 목표 및 실습 개요

- 도메인 이름이 어떻게 IP로 변환되고, 패킷이 어떤 경로를 따라 목적지까지 도달하는지를 시각적으로 이해하기

- Windows 명령어(`nslookup`, `tracert`)와 Wireshark를 활용해 DNS 질의와 TCP 연결 흐름을 분석

실습 환경 (운영체제, 네트워크 상태)
- Windows, WiFi

실습 순서 
1.DNS 질의 실습 – nslookup, Wireshark
2.TCP 연결 경로 분석 – tracert, Wireshark

분석 결과 요약

느낀점

 

Wireshark is a free and open-source packet analyzer. It is used for network troubleshooting, analysis, software and communications protocol development, and education. Originally named Ethereal, the project was renamed Wireshark in May 2006 due to trademark issues.

 

와이어샤크는 무료 오픈 소스 패킷 분석 프로그램이며, 네트워크 트러블 슈팅과 분석, SW와 통신 프로토콜 개발, 교육에 사용된다고 한다. 원래 이름은 Ethereal이었으나, 상표 문제로 인해 2006년에 와이어샤크로 개명했다고 합니다.

 

 

 

1. DNS 질의 실습 – nslookup, Wireshark

- 도메인 네임을 입력했을 때, 실제로 어떤 과정으로 IP를 찾아가는지를 보기 위해 `nslookup` 명령어와 Wireshark를 활용해 DNS 질의/응답 과정을 확인

 

내용: nslookup으로 도메인 정보 요청

 

nslookup은 DNS 서버에 질의하여, 도메인의 정보를 조회 하는 명령어이다.

CMD에서 nslookup으로 조회한 내용을 Wireshark가 실시간으로 데이터를 캡쳐(포획)하고 해당 패킷을 기록해둔 파일에 대한 정보를 읽을 수 있다.  

 

 

 

WireShark에서 패킷 확인

 

필터창에 dns 키워드 입력으로, protocol이 DNS인 패킷만 볼 수 있다.

원하는 내용(패킷)을 클릭하거나 더블 클릭하여, 하단에 상세 내용에서 요청한 도메인 정보에 관한 패킷 내용을 확인할 수 있다.

 

나는 처음 www.google.com에  대한 내용을 요청했다.   

그런데, 요청 내용이 두 개가 들어왔다.

 

 

WireShark에서 패킷 확인

 

 

두 레코드의 차이는 "프로토콜 차이"로 확인되었다.

 

패킷 비교

No.	Source → Destination	Type	Query	설명
71	192.168.0.100 → 192.168.0.1	A	www.google.com	IPv4 주소 요청
73	192.168.0.100 → 192.168.0.1	AAAA	www.google.com	IPv6 주소 요청

- 71번은 A 레코드로 IPv4 주소를 요청하는 DNS 요청

- 73번은 AAAA 레코드로 IPv6 주소를 요청하는 DNS 요청

 

 

 

IPv4, IPv6 요청 패킷 비교

 

 

 

IPv4, IPv6 응답 패킷 비교

 

클라이언트는 www.google.com에 접속하기 위해 DNS 서버(192.168.0.1)에 A와 AAA 두 가지 레코드 요청을 보낸 거였고

-  A 레코드는 IPv4 주소로 요청 (Address: 142.250.197.196)

- AAA 레코드는 IPv6 주소로 요청 (AAAA Address: 2404:6800:4005:81b::2004)

 

Wireshark를 통해 두 요청이 0.012초 간격으로 동시에 이루어졌음을 확인할 수 있었고(Time 탭), 이는 클라이언트가 IPv6 환경을 지원할 경우 먼저 시도하는 일반적인 동작임을 알게 되었습니다.

 

A 레코드 요청은 12.066908초에, AAAA 레코드 요청은 12.078997초에 발생하여
약 12ms 간격으로 동시에 요청되었음을 확인할 수 있습니다.

 

 

대부분 최신 OS는 IP6를 먼저 시도하고 사용 가능한 경우 연결하려고 함
그래서 위 두 레코드를 동시에 요청하는 것임

 

 

 

 

 

 

 

2. TCP 연결 경로 분석 – tracert, Wireshark

- 트레이스 라우트(`tracert`)를 통해 패킷이 목적지까지 도달하는 경로(Hop)를 확인하고, 이를 기반으로 네트워크의 실제 흐름을 시각화

 

 

 

 

TCP 연결 경로 분석하여 패킷이 어떤 경유지(Hop)를 거쳐 최종 목적지까지 가는지 정확히 추적해보겠습니다.

 

 

 

 

 

 

tracert 명령 실행

tracert 명령어 실행

 

 

 

 

 

 

 

 

 

 

 

Wireshark 패킷 필터링

- icmp 키워드로 필터링

- tracert는 목적지에 도달하기 전까지 ICMP Time Exceeded, 도달하면 ICMP Echo Reply 패킷 받기 때문에 icmp 키워드 필터가 적합

 

1번 

 

2번

 

 

3번

 

4번

 

 

 

 

 

많은 내용들이 리스팅되었다!

먼저, 내용들을 이해하기 위해 TTL(Time To Live) 원리 이해해야 한다.

TTL은 괄호안 영어 뜻처럼 "살아 있는 시간" 즉, "트래픽 생존 시간", "패킷이 지나갈 수 있는 최대 라우터 수"이라고 생각하면 된다.

tracert는 목적지에 도달하지 못하게 TTL을 1부터 시작해서 1씩 증가한다.

TTL이 0이 되면 라우터는 "Time Exceeded" (ICMP Type 11) 메시지를 보내며, 이 응답으로 중간 경로 IP를 알아낼 수 있다.

 

예를 들어, 패킷 1 (TTL=1)가 있다고 한다.

= 첫 번째 라우터에서 Drop -> ICMP Time Exceeded 라고 해석할 수 있다.

= 첫 번째 라우터까지만 도달한 뒤, 더 이상 갈 수 없기 때문에 라우터가 이를 감지하고 "수명이 다 됐다"고 알려주는 응답 (ICMP Time Exceeded)을 클라이언트에게 돌려보낸다.

 

Drop
: 라우터가 패킷을 폐기함 (더 이상 못 가니까 여기서 멈춤)

TTL (Time To Live)
: 패킷이 지나갈 수 있는 최대 라우터 수 (이동 제한 거리)


ICMP Time Exceeded
: TTL이 0이 되었음을 알리는 메시지 (이 패킷은 수명을 다했어요"라고 알림)

 

 

 

아무튼, 전체 흐름을 요약하면

tracert www.google.com 실행 후  최종 목적지까지 17 hops 걸렸다는 사실을 알 수 있다.

단계	내용
TTL=1 ~ TTL=16	여러 라우터를 거치며 Time Exceeded 또는 Destination Unreachable 응답을 받음
TTL=17	최종 목적지(142.250.198.36)에서 Echo Reply가 도착함

목적지 서버의 초기 TTL
Windows: 128
Linux/Google 서버: 64
Cisco 라우터: 255

 

 

 

No. 89241 ~ 89245 ICMP Echo (ping) reply from 142.250.198.36 (목적지)

내용
89241 2469.443165 192.168.0.100 142.250.198.36 ICMP 106 Echo (ping) request id=0x0001, seq=158/40448, ttl=17 (reply in 89242)

89243 2469.512353 192.168.0.100 142.250.198.36 ICMP 106 Echo (ping) request id=0x0001, seq=159/40704, ttl=17 (reply in 89244)

89245 2469.582449 192.168.0.100 142.250.198.36 ICMP 106 Echo (ping) request id=0x0001, seq=160/40960, ttl=17 (reply in 89253)

 

 

또한, 중간 경유지(Hop)들을 확인할 수 있었다.

- 내부 게이트웨이

- 접근 제한된 라우터 (Communication administratively filtered)

 

Communication administratively filtered
- 해당 라우터가 ICMP 응답 허용하지 않는다는 뜻으로, 중간 라우터가 ping이나 tracert 요청에 응답하지 않도록 보안 정책이 걸려있는 상태라고 볼 수 있다. 
- 보통 방화벽이나 ISP 라우터에서 발생

 

 

 

 

 

 

 

 

 

분석 결과 요약

- DNS 요청은 클라이언트 → DNS 서버 간 요청/응답 구조
- tracert는 TTL 값을 증가시키며 ICMP Time Exceeded 패킷으로 경로 확인
- Wireshark를 통해 실제 네트워크 동작을 시각적으로 이해 가능

 

 

 

 

 

 

 

 

 

 

 

느낀 점

- 이번 실습을 통해 평소에 잘 인식하지 못했던 DNS 요청 및 통신 경로 과정을 직접 눈으로 확인할 수 있었습니다. 실제 업무나 장애 대응 시 어떤 흐름으로 디버깅할 수 있을지 감이 생겼습니다.