Step 33. DNS — 인터넷의 전화번호부

Level 0 — 컴퓨터 조작과 구조의 이해 | 난이도 ★★★☆☆ | 예상 소요 시간 3시간

전제: Step 31~32(IP, ARP) 완료. 윈도우 파워쉘에서 진행합니다. hosts 파일 실험에만 관리자 권한이 필요합니다.

준비물: 윈도우 PC, 파워쉘, (hosts 실험용) 관리자 권한 메모장.
주의: 조회 명령은 안전합니다. hosts 파일을 고치는 실험이 하나 있는데, 끝나면 반드시 원상복구합니다 — 절차에 복구와 확인 단계가 포함되어 있습니다.

여러분은 매일 naver.com, google.com을 칩니다. 그런데 지난 두 챕터에서 배웠듯, 컴퓨터끼리의 통신은 숫자(IP)로 이루어집니다. "google.com"이라는 글자는 통신에 못 씁니다. 그렇다면 누가 이 이름을 숫자로 바꿔 줄까요?

그 일을 하는 거대한 세계 전화번호부가 DNS(Domain Name System)입니다. 이 번호부가 멈추면 인터넷도 사실상 멈춥니다 — 사람들이 "142.251.118.101"을 외우고 다닐 수는 없으니까요. 오늘은 이 번호부에 직접 질문을 던져 보고, 여러분 PC 안의 작은 수동 번호부(hosts 파일)까지 손대 봅니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

DNS가 "이름 → IP"를 바꿔 주는 계층적 시스템임을 설명한다
브라우저에 주소를 친 뒤 IP를 얻기까지의 과정을 다섯 단계로 말한다
nslookup과 Resolve-DnsName으로 이름을 직접 조회하고 답을 읽는다
TTL이 무엇이며, 조회할 때마다 줄어드는 모습을 관찰한다
hosts 파일의 우선순위와 위험성을 설명하고, 실험 후 원상복구를 확인한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	파워쉘 5.1. hosts 실험 시 관리자 권한 메모장 1회 사용
오늘의 명령어	`nslookup 이름 [서버]`, `Resolve-DnsName 이름`, `ipconfig /flushdns`, `Get-Content …\etc\hosts`
필요한 개념	도메인 계층, 리커시브 조회, DNS 캐시와 TTL, A 레코드, hosts 파일의 우선순위

2-1. 이름의 계층 — 주소를 거꾸로 읽기

도메인 이름은 점(.)으로 나뉜 계층 구조입니다. 그런데 읽는 방향이 주소와 반대입니다. www.example.co.kr은 오른쪽이 큰 단위입니다.

www   . example   . co   . kr
(호스트) (기관 이름)  (회사)  (한국)

맨 위에는 루트(root)라는 세계 최상위 번호부가 있고, 그 아래 .kr, .com 같은 최상위 도메인(TLD, Top-Level Domain)들이 있고, 그 아래에 각 기관의 이름이 매달립니다. 전화번호부가 한 권이 아니라 계급처럼 나뉜 조직이라고 생각하세요.

2-2. 리커시브 조회 — 모르면 위에 물어보기

여러분이 google.com을 치면 일어나는 일:

내 PC가 먼저 뒤진다: 내 기억(캐시)과 hosts 파일을 본다.
DNS 서버에게 묻는다: 모르면 설정된 DNS 서버(보통 공유기나 통신사가 정해 준 것)에게 묻는다.
DNS 서버가 대신 찾아준다: 그 서버도 모르면 루트 → .com → google 순으로 계급을 따라 물어물어 답을 얻는다. 이것이 리커시브 조회(recursive query, 재귀 조회)입니다.
답을 받고 기억한다: 얻은 IP를 알려 주고, 다음을 위해 잠시 기억해 둡니다.

즉 여러분은 매번 세계 최고 권위의 서버에 묻는 게 아니라, "대신 찾아주는 사서"에게 묻는 것이고, 그 사서가 위계를 따라 찾아 줍니다.

2-3. TTL — 기억의 유효 시간

DNS 답에는 TTL(Time To Live)이라는 숫자가 붙습니다. "이 답을 몇 초 동안 기억해도 좋다"는 유효 시간입니다. 캐시에 저장된 답은 TTL이 1초씩 깎이고, 0이 되면 버리고 새로 물어봅니다.

TTL 덕분에 전 세계가 같은 질문을 반복하지 않고도 빠릅니다. 반대로, 사이트가 주소를 바꿨을 때 예전 답을 기억 중인 컴퓨터는 TTL이 끝날 때까지 옛날 주소로 갑니다. 이 "기억의 시차"가 뒤의 실험과 연습문제에서 다시 나옵니다.

2-4. hosts 파일 — 내 책상 서랍의 쪽지

2-2의 1단계에서 "내 PC가 먼저 뒤진다"고 했죠. 그중 하나가 hosts 파일입니다. DNS보다 먼저 참조되는, 컴퓨터 안의 수동 전화번호부입니다. 여기에 127.0.0.1 test.local이라고 적어 두면, 이 컴퓨터는 test.local을 물을 때 DNS에 묻지도 않고 127.0.0.1로 갑니다.

hosts 파일의 나이는 DNS보다 많습니다. 인터넷의 전신 시절, 컴퓨터가 몇십 대뿐이던 때는 중앙 서버의 hosts 파일 하나를 내려받아 쓰는 것이 전부였습니다. 컴퓨터가 늘어나자 DNS가 등장했지만, "내 서랍의 쪽지가 공식 번호부보다 우선"이라는 규칙만은 남았습니다.

관리자들은 개발·시험 용도로 이 파일을 씁니다. 그런데 이 우선순위가 악용되면? naver.com을 가짜 IP로 적어 넣으면, 사용자는 올바른 이름을 쳤는데 가짜 사이트로 갑니다. 이것이 고전적인 hosts 오염 공격(파밍의 한 형태)입니다. 오늘 실험 후 반드시 원상복구하는 이유입니다.

3. 따라 하기

3-1. 이름을 물어보기 — nslookup

nslookup naver.com

Server:  kns.kornet.net
Address:  168.126.63.1

Non-authoritative answer:
Name:    naver.com
Addresses:  223.130.200.219
            223.130.192.247
            223.130.192.248
            223.130.200.236

(2026-09-09 실측. 여러분의 DNS 서버와 받는 주소는 다를 수 있습니다.)

출력 읽는 법: 위쪽(Server/Address)은 "누구에게 물었나" — 지금은 통신사의 DNS 서버(사서)입니다. 아래쪽(Name/Addresses)이 받은 답입니다. 주소가 네 개인 것에 주목하세요 — 큰 서비스는 여러 서버에 접속을 나누기 위해 하나의 이름에 여러 주소를 붙여 둡니다.

Non-authoritative answer(비권위 응답)는 "이 답은 그 도메인의 주인 서버가 아니라, 기억해 둔 것을 대답한 것"이라는 뜻입니다. 캐시에서 온 정상적인 답입니다.

3-2. 다른 사서에게 물어보기

명령 뒤에 서버 주소를 붙이면 사서를 바꿀 수 있습니다. 8.8.8.8은 구글이 운영하는 공개 DNS입니다.

nslookup google.com 8.8.8.8

Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    google.com
Addresses:  172.217.213.139
            172.217.213.138
            172.217.213.101
            ...

(2026-09-09 실측.)

출력 읽는 법: 사서가 dns.google(8.8.8.8)로 바뀌었습니다. 그런데 같은 날 기본 사서(통신사 DNS)에게 물었을 때는 142.251.118.x 대의 주소가 나왔습니다 — 두 사서의 답이 다릅니다!

이것은 고장이 아닙니다. 구글 같은 거대 서비스는 세계 곳곳에 서버를 두고, 사서가 가진 기억(캐시)과 위치에 따라 다른 서버 주소를 알려 줍니다. "답이 다르다"가 곧바로 "오염됐다"는 뜻은 아니지만, 다르다는 사실 자체가 조사의 시작점이라는 감각은 가져가세요.

3-3. TTL이 깎이는 것을 보기 — Resolve-DnsName

파워쉘답게 표로 보여 주는 명령도 있습니다.

Resolve-DnsName naver.com -Type A | Format-Table Name, Type, TTL, IPAddress

Name      Type TTL IPAddress
----      ---- --- ---------
naver.com    A 157 223.130.192.247
naver.com    A 157 223.130.192.248
naver.com    A 157 223.130.200.219
naver.com    A 157 223.130.200.236

(2026-09-09 실측.)

출력 읽는 법: Type A는 "이름 → IPv4 주소"라는 답의 종류(레코드) 표시이고, TTL 157은 "이 답을 앞으로 157초 더 기억한다"는 뜻입니다.

같은 명령을 잠시 후에 다시 치면 TTL이 줄어 있습니다. 실측에서는 20초 간격으로 두 번 쳤더니:

첫 번째 조회: TTL 32
(20초 후)
두 번째 조회: TTL 108

(2026-09-09 실측.)

읽는 법: 첫 조회 때는 캐시에 32초만 남은 답이 있었고, 그 사이 유효 시간이 끝나 새로 물어온 답(108초)이 보인 것입니다. "TTL은 깎이고, 0이 되면 새로 묻는다"가 숫자로 확인됐습니다. 여러분도 같은 명령을 두 번, 간격을 두고 쳐 보세요.

3-4. hosts 파일 열어 보기

hosts 파일의 위치는 C:\Windows\System32\drivers\etc\hosts입니다. 먼저 읽기만 해 봅시다(읽기는 일반 권한으로 됩니다):

Get-Content C:\Windows\System32\drivers\etc\hosts

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# ...
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost

(2026-09-09 실측. 중간의 영어 설명 줄들을 일부 줄였습니다. 실측 컴퓨터에는 이 아래에 가상 사설망 프로그램이 자동으로 관리하는 줄 몇 개가 더 있었습니다 — 여러분의 파일에도 설치한 프로그램이 추가한 줄이 있을 수 있습니다.)

출력 읽는 법: #으로 시작하는 줄은 전부 주석(설명문)이라 효력이 없습니다. 기본 상태의 hosts는 사실상 빈 번호부입니다 — 적힌 것이 없어야 정상입니다. # 없이 시작하는 실제 등록 줄이 보이면, 그 줄을 누가 왜 적었는지 확인할 가치가 있습니다.

3-5. hosts 실험 — 쪽지의 힘을 확인하기

⚠️ 이 실험은 시스템 파일을 고칩니다. 순서대로 진행하고, 마지막에 반드시 되돌립니다.

시작 메뉴에서 메모장을 우클릭 → 관리자 권한으로 실행하고, 그 메모장에서 C:\Windows\System32\drivers\etc\hosts를 엽니다. 맨 아래에 새 줄을 추가합니다:

127.0.0.1   test.local

저장 후 닫습니다(저장이 안 되면 메모장을 관리자로 안 연 것입니다). 이제 확인:

ping test.local

Pinging test.local [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

(출력 예시 — 이 실험은 여러분이 관리자 권한으로 직접 진행하는 단계입니다.)

읽는 법: 세상에 없는 이름 test.local이 127.0.0.1(나 자신, Step 31의 루프백)로 풀렸습니다. DNS에 묻지도 않고, 내 컴퓨터 서랍의 쪽지대로 움직인 것입니다.

반드시 — 원상복구: 다시 관리자 메모장으로 hosts를 열어 방금 추가한 줄을 삭제하고 저장합니다. 그리고 확인:

Get-Content C:\Windows\System32\drivers\etc\hosts
ping test.local

파일에 방금 줄이 없고, ping이 "호스트를 찾을 수 없다"고 하면 복구 완료입니다. "지웠다"가 아니라 "확인했다"가 실무의 언어입니다.

왜: 이 실험의 요점은 "된다"가 아니라 우선순위입니다. hosts > DNS. 이 한 줄의 힘이 얼마나 큰지, 그래서 왜 이 파일이 공격자의 표적이 되는지를 손으로 확인한 것입니다.

3-6. 캐시 비우기 — ipconfig /flushdns

컴퓨터가 기억하던 DNS 답안지를 전부 버리는 명령입니다.

ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

(2026-09-09 실측. 한글 윈도우에서는 "DNS 확인자 캐시를 플러시했습니다" 류로 나옵니다.)

읽는 법: 사이트가 주소를 바꿨는데 자꾸 옛날로 접속될 때 쓰는 응급 처치입니다. 캐시를 비우면 다음 조회부터 사서에게 새로 물어봅니다. hosts 파일은 이 명령으로 지워지지 않습니다 — hosts는 캐시가 아니라 설정 파일이기 때문입니다.

3-7. 다섯 단계로 말하기 연습

브라우저에 www.example.com을 치고 Enter를 누른 순간의 여정을 소리 내어 말해 보세요.

내 캐시와 hosts 파일을 뒤진다.
없으면 내 DNS 서버(사서)에게 묻는다.
사서가 계급을 따라 찾는다(루트 → TLD → 기관).
답(IP)을 받아 기억한다.
그 IP로 웹 서버에 연결한다.

이 다섯 문장이 막힘 없이 나오면 오늘 챕터의 절반을 달성한 것입니다.

3-8. 진단 연습 — "인터넷이 안 돼요"

오늘 배운 도구만으로 진단 순서를 연습합니다. 열쇠는 두 질문의 조합입니다: "숫자로 되나? 이름으로 되나?"

상황 A — DNS 의심: ping 8.8.8.8은 응답이 오는데(2026-09-09 실측: 33ms로 응답 확인), ping google.com이 실패합니다.

→ 진단: 숫자는 되고 이름은 안 됩니다. 연결은 살아 있고 번호부가 고장 난 상태 — DNS 문제입니다. 설정된 DNS 서버를 확인하거나, 임시로 공개 DNS(8.8.8.8)를 쓰도록 바꾸면 복구되는 경우가 많습니다.

상황 B — 연결 자체 의심: ping <게이트웨이>조차 응답이 없습니다.

→ 진단: 이름 이전의 문제, 물리 연결의 고장입니다. 케이블, 와이파이 연결부터 봅니다. DNS를 아무리 만져도 이 단계에서는 소용없습니다.

읽는 법: "아래층부터 위로"가 진단의 철칙입니다. 연결(1층) → 주소와 게이트웨이(2층) → DNS(3층) → 프로그램(4층).

4. 미션과 연습문제

미션 — DNS 조사 카드 만들기

nslookup으로 naver.com, daum.net, github.com 셋을 조회해 주소를 적으세요
같은 세 이름을 8.8.8.8 사서에게도 물어 보고, 기본 사서의 답과 비교하세요 (다른 항목이 있었나요? 있다면 왜 다를 수 있는지 한 줄로 적으세요)
Resolve-DnsName으로 한 이름을 골라 TTL을 기록하고, 1~2분 뒤 다시 조회해 TTL 변화를 적으세요
결과 전부를 dns-card.txt에 정리하세요

연습문제

문제 1. 브라우저에 주소를 치고 IP를 얻기까지의 다섯 단계를 순서대로 말하세요.

문제 2. 어떤 컴퓨터에서 naver.com을 쳤더니 이상한 사이트로 연결됩니다. 그런데 옆 컴퓨터에서는 정상입니다. 가장 먼저 의심할 파일과 그 이유를 말하세요.

문제 3. ipconfig /flushdns는 무엇을 지우는 명령이며, hosts 파일의 내용은 왜 이 명령으로 안 지워질까요?

문제 4. "ping 8.8.8.8은 되는데 ping google.com은 안 된다"는 신고를 받았습니다. 어느 층의 문제이며, 다음으로 무엇을 확인하겠습니까?

5. 모범 답안과 완료 기준

미션 모범 답안

실측 컴퓨터의 예 (2026-09-09):

[기본 사서: 168.126.63.1 (통신사 DNS)]
naver.com   → 223.130.200.219 외 3개
google.com  → 142.251.118.101 외 다수

[8.8.8.8 사서 (dns.google)]
google.com  → 172.217.213.139 외 다수  ← 기본 사서와 주소가 다름
차이의 이유:  대형 서비스는 여러 서버에 주소를 나눠 두고,
             사서의 캐시·위치에 따라 다른 답을 줌 (정상)

[TTL 관찰: naver.com]
1차 조회 TTL 32 → (20초 뒤) 2차 조회 TTL 108
해석: 캐시 답이 만료되어 새로 물어온 답이 보임

검증하는 법: ① 세 이름 모두 IP가 숫자로 돌아왔는가. ② 두 사서 비교표가 채워졌는가. ③ TTL 두 번의 숫자가 기록됐는가 — 줄어 있거나(캐시 유지 중) 다시 커져 있거나(재조회) 둘 중 하나이며, 둘 다 정상입니다. 주소가 다르면 틀린 게 아니라 관찰 포인트라는 것이 이 미션의 핵심입니다.

연습문제 해답

문제 1 해답. ① 내 캐시와 hosts 파일을 뒤진다 → ② 없으면 내 DNS 서버에게 묻는다 → ③ 그 서버가 루트 → TLD → 기관 순으로 대신 찾는다(리커시브 조회) → ④ 답(IP)을 받아 TTL 동안 기억한다 → ⑤ 그 IP로 웹 서버에 연결한다.

문제 2 해답. 그 컴퓨터의 hosts 파일입니다. hosts는 DNS보다 먼저 참조되는 컴퓨터별 수동 번호부라서, 한 대만 오염되는 일이 가능합니다. Get-Content C:\Windows\System32\drivers\etc\hosts로 # 없이 시작하는 줄이 있는지 확인합니다. 옆 컴퓨터가 정상이라는 것은 "세계의 번호부는 멀쩡하고 이 컴퓨터만 다르게 안다"는 뜻이니, 조사가 내 컴퓨터 안쪽으로 좁혀집니다.

문제 3 해답. 컴퓨터가 기억하던 DNS 답(리졸버 캐시)을 전부 버리는 명령입니다. hosts 파일은 캐시가 아니라 디스크 위의 설정 파일이라 이 명령의 대상이 아닙니다 — 캐시는 기억(TTL이 지나면 저절로 사라짐), hosts는 설정(직접 지우기 전까지 영구)입니다.

문제 4 해답. 연결(1~2층)은 살아 있고 이름 해석(3층)이 고장 난 상태, 즉 DNS 문제입니다. 다음 확인: ① nslookup google.com으로 사서가 답하는지 본다. ② 안 되면 nslookup google.com 8.8.8.8로 다른 사서에게 물어 본다 — 되면 내 기본 DNS 서버의 고장이고, 그것도 안 되면 상위 연결 문제로 범위를 넓힙니다.

완료 기준 체크리스트

[ ] 브라우저 주소 입력 후 IP를 얻는 다섯 단계를 말할 수 있다
[ ] nslookup 출력에서 "누구에게 물었나"와 "받은 답"을 구분해 읽는다
[ ] 사서를 지정해(… 8.8.8.8) 조회할 수 있다
[ ] TTL의 의미를 알고, 두 번 조회해 변화를 관찰했다
[ ] hosts 파일의 우선순위와 위험성을 설명할 수 있다
[ ] hosts 실험을 했다면 원상복구를 Get-Content와 ping으로 확인했다
[ ] 미션: dns-card.txt를 완성했다

6. 흔한 실수와 해결

벽 1. "hosts를 수정했는데 저장이 안 돼요."

증상: 저장 시 "액세스가 거부되었습니다"가 뜹니다.

원인: hosts는 시스템 파일이라 일반 권한으로는 못 고칩니다. 최소 권한 원칙이 지키는 대표 파일입니다.

해결: 메모장을 관리자 권한으로 실행(시작 메뉴에서 우클릭)한 뒤 그 안에서 파일을 열어 고치세요. 파일을 먼저 연 창에서는 권한이 안 올라갑니다.

벽 2. "없는 이름을 쳤는데 이상한 답이 와요 / nslookup의 답이 두 부분이에요."

증상: 없는 이름을 조회하면 이런 메시지를 봅니다 (2026-09-09 실측):

*** kns.kornet.net can't find test.local: Non-existent domain
Server:  kns.kornet.net
Address:  168.126.63.1

원인: 위쪽은 "사서의 대답"(그런 이름 없음), 아래쪽은 "누가 대답했나"입니다. 읽는 순서만 알면 오류가 아니라 정상적인 부정 응답입니다. 같은 이름으로 ping을 치면 "Ping request could not find host test.local. Please check the name and try again."(2026-09-09 실측)이라고 나옵니다.

해결: Non-existent domain은 "세계 어디에도 그 이름은 없다"는 깨끗한 실패입니다. 오타부터 확인하세요.

벽 3. "hosts를 고쳤는데 적용이 안 돼요."

증상: 줄을 추가했는데 ping이 예전대로입니다.

원인: 의심 순서는 셋입니다. ① 저장이 실제로 됐나(관리자 권한) ② 이름을 정확히 쳤나(띄어쓰기·오타) ③ 브라우저는 자체 캐시를 쓰는 경우가 있어 ping과 다르게 동작할 수 있음.

해결: ping은 시스템의 이름 해석을 쓰니 hosts가 즉시 반영되는 확인 도구로 좋습니다. 저장 후 ping으로 먼저 확인하세요.

벽 4. "실험 후 hosts를 되돌렸는지 불안해요."

증상: 줄을 지운 것이 맞는지 기억이 안 납니다.

원인: 실습 중 편집은 흔적이 헷갈리기 쉽습니다.

해결: Get-Content C:\Windows\System32\drivers\etc\hosts로 직접 눈으로 확인하세요. # 주석과 여러분이 아는 정상 등록 줄 외에 모르는 줄이 없으면 됩니다. 그리고 3-5절의 마지막 확인 ping이 "찾을 수 없다"고 하면 복구된 것입니다.

벽 5. "nslookup은 되는데 인터넷이 안 돼요(또는 그 반대)!"

증상: 이름 조회는 되는데 접속이 안 되거나, IP로는 되는데 이름으로는 안 됩니다.

원인: 이 조합이 진단의 열쇠입니다. IP로 되고 이름으로 안 되면 = DNS 문제. 둘 다 안 되면 = 연결 자체 문제.

해결: "숫자로 되나? 이름으로 되나?" 이 두 질문을 항상 세트로 물으세요. 3-8절의 사다리(연결 → 주소 → DNS → 프로그램)를 아래층부터 올라가면 됩니다.

7. 정리

오늘의 개념

개념	한 줄 설명
DNS	이름을 IP로 바꾸는 세계적 계층 번호부
리커시브 조회	사서(DNS 서버)가 계급을 따라 대신 찾아 주는 방식
A 레코드	"이름 → IPv4 주소" 답의 종류 (AAAA는 IPv6)
TTL	캐시된 답의 유효 시간(초) — 깎이다가 0이면 재조회
캐시	한 번 얻은 답의 임시 기억 (`ipconfig /flushdns`로 비움)
hosts 파일	DNS보다 먼저 보는 수동 번호부 — 강력하고 위험
비권위 응답	캐시에서 온 정상적인 대답이라는 표시

오늘의 명령어

명령	하는 일
`nslookup 이름`	기본 DNS 서버에 이름 조회
`nslookup 이름 8.8.8.8`	사서를 지정해 조회
`Resolve-DnsName 이름 -Type A`	TTL까지 표로 조회
`ipconfig /flushdns`	DNS 캐시 비우기
`Get-Content …\drivers\etc\hosts`	hosts 파일 내용 확인(읽기)

명령어보다 중요한 감각

"숫자로 되나? 이름으로 되나?" — 이 두 질문이 네트워크 진단의 첫 갈림길입니다. "인터넷이 안 돼요"라는 한 줄의 불평도 이제 "어느 층의 문제인가"로 번역할 수 있습니다.

그리고 기억하세요. 이름에서 숫자로 가는 길에는 여러 손(캐시, hosts, 사서, 계급의 서버들)이 닿아 있고, 그중 하나가 오염되면 이용자의 화면에는 아무 이상 표시가 없습니다. 주소창에 올바른 이름을 쳤는데도 속을 수 있다는 것 — 그것을 아는 것이 오늘의 보안 수확입니다.

전부 체크되면 Step 33 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.