🌐 DNS 서버 기초

DNS가 필요한 이유

DNS 도메인 IP 변환 — DNS는 사람이 읽는 도메인 이름을 컴퓨터가 접속할 IP 주소로 바꿔 준다.

DNS는 사람이 읽기 쉬운 도메인 이름을 컴퓨터가 접속할 수 있는 IP 주소로 바꿔 주는 시스템입니다. 사용자는 school-login.test 같은 이름을 입력하지만, 실제 네트워크는 192.168.56.x 같은 IP 주소를 목적지로 사용합니다.

이 프로젝트에서 DNS는 가장 중요한 전환점입니다. DNS 응답 IP가 정상 웹 서버를 가리키면 정상 페이지가 열리고, 실습용 경고 페이지 서버를 가리키면 같은 도메인을 입력해도 다른 화면이 열립니다.

이 장의 목표는 DNS 서버를 복잡하게 운영하는 것이 아니라, “무엇을 물어봤고, 어떤 IP를 받았으며, 그 다음 어디로 접속했는가”를 쉽게 설명하는 것입니다.

그림으로 보는 DNS 흐름

DNS 기본 동작 순서 — 사용자가 도메인을 입력하면 DNS 질의와 응답을 거쳐 웹 서버 IP를 얻는다.

DNS 응답 IP는 이후 웹 접속 목적지를 결정합니다.그래서 Wireshark에서는 DNS Response의 Answers 영역과 이후 TCP 목적지 IP를 함께 봐야 합니다.

쉽게 말하면DNS는 인터넷의 전화번호부입니다. 사람은 이름을 기억하고, 컴퓨터는 번호(IP)를 사용합니다. 이 전화번호부가 다른 번호를 알려주면 같은 이름을 눌러도 다른 곳으로 전화가 걸립니다.

DNS 질의와 응답

브라우저가 웹 서버에 접속하기 전에 운영체제는 먼저 DNS 질의를 보냅니다. 이 질의에는 사용자가 요청한 도메인 이름이 들어 있고, DNS 서버는 해당 도메인에 대응되는 IP 주소를 응답합니다.

Wireshark에서는 DNS Query와 DNS Response를 구분할 수 있습니다. Query는 “무엇을 물어봤는가”이고, Response는 “어떤 IP를 받았는가”입니다. DNS를 공부할 때는 질문과 답을 항상 한 쌍으로 보는 습관이 중요합니다.

도메인 계층 구조

DNS 재귀 질의 흐름 — Local DNS가 Root, TLD, Authoritative DNS를 거쳐 최종 IP 주소를 찾는 과정

도메인은 오른쪽에서 왼쪽으로 큰 범위에서 작은 범위로 내려갑니다. 예를 들어 www.example.com에서 com은 최상위 도메인에 가깝고, example은 그 아래 도메인, www는 특정 호스트 이름입니다.

실제 인터넷에서는 Root, TLD, Authoritative DNS 같은 계층을 거쳐 답을 찾습니다. 하지만 이 프로젝트의 내부 실습망에서는 구조를 단순화해서 .test 도메인과 내부 DNS 서버만으로 원리를 설명할 수 있습니다.

레코드와 TTL

주요 DNS 레코드 종류 — A, AAAA, CNAME, MX, NS, TXT, PTR 레코드는 각각 다른 종류의 DNS 정보를 담는다.

A 레코드는 도메인을 IPv4 주소로 연결합니다. 실습에서는 school-login.test가 정상 안내 페이지 IP 또는 교육용 경고 페이지 IP를 가리키도록 구성할 수 있습니다.

CNAME은 별칭, MX는 메일 서버, NS는 네임서버, TXT는 문자열 정책 정보를 나타냅니다. 처음에는 A 레코드와 TTL만 확실히 이해해도 DNS 흐름을 따라가는 데 충분합니다.

TTL은 Time To Live의 줄임말로, DNS 응답을 얼마 동안 캐시에 저장해도 되는지 알려 주는 값입니다. 예를 들어 TTL이 300초라면 해당 응답은 5분 동안 다시 물어보지 않고 재사용될 수 있습니다.

TTL이 짧으면 DNS 변경 사항이 비교적 빨리 반영되지만, DNS 서버에 더 자주 물어보게 됩니다. 반대로 TTL이 길면 접속 속도와 서버 부담 면에서는 유리하지만, IP 주소를 바꿨을 때 이전 응답이 오래 남아 있을 수 있습니다. 그래서 TTL은 속도와 변경 반영 시간 사이의 균형을 정하는 값이라고 보면 됩니다.

DNS 캐시와 TTL

DNS 캐시는 같은 도메인을 반복해서 물어보지 않도록 DNS 응답을 잠시 저장하는 기능입니다. 캐시가 없으면 브라우저가 같은 사이트에 접속할 때마다 매번 DNS 서버에게 “이 도메인의 IP가 뭐야?”라고 물어봐야 합니다. 그러면 접속이 느려지고 DNS 서버에도 불필요한 요청이 많이 쌓입니다.

캐시는 이런 반복 질문을 줄이기 위해 사용됩니다. 처음 school-login.test를 조회해서 192.168.56.30이라는 응답을 받았다면, 운영체제나 DNS 서버는 그 결과를 TTL 동안 기억합니다. 그 뒤 같은 도메인을 다시 요청하면 원래 DNS 서버까지 다시 가지 않고 저장해 둔 값을 바로 사용할 수 있습니다.

쉽게 말하면DNS 캐시는 전화번호를 한 번 찾아본 뒤 메모장에 적어 두는 것과 비슷합니다. 같은 사람에게 다시 전화할 때 전화번호부를 처음부터 다시 뒤지지 않고, 메모장에 적힌 번호를 바로 사용하는 방식입니다.

DNS 캐시는 여러 위치에 생길 수 있습니다. 브라우저가 자체적으로 기억할 수도 있고, Windows나 Linux 같은 운영체제가 기억할 수도 있습니다. 집이나 학교의 공유기가 DNS 전달자 역할을 하면서 캐시할 수도 있고, 통신사나 공용 DNS 서버 같은 재귀 DNS 서버가 많은 사용자를 위해 응답을 저장해 둘 수도 있습니다.

캐시 위치	역할	헷갈릴 수 있는 상황
브라우저 캐시	브라우저가 최근 도메인 결과를 기억	브라우저만 재시작해도 결과가 달라질 수 있음
운영체제 DNS 캐시	Windows/Linux가 DNS 응답을 임시 저장	명령어와 브라우저 결과가 이전 IP를 계속 볼 수 있음
공유기/로컬 DNS 캐시	내부 장치들의 DNS 요청을 대신 처리하고 저장	여러 PC가 같은 이전 응답을 공유할 수 있음
재귀 DNS 서버 캐시	통신사, 회사, 공용 DNS 서버가 응답을 저장	내 PC 캐시를 지워도 외부 DNS 서버가 이전 값을 줄 수 있음

캐시는 보통 좋은 기능입니다. 자주 방문하는 사이트의 접속을 빠르게 만들고, DNS 서버가 같은 질문을 반복해서 처리하지 않게 해 줍니다. 특히 사용자가 많은 학교, 회사, 통신사 환경에서는 캐시 덕분에 DNS 트래픽이 크게 줄어듭니다.

하지만 DNS 설정을 바꾸는 순간에는 캐시가 혼란을 만들 수 있습니다. 예를 들어 school-login.test의 IP를 바꿨는데 브라우저가 여전히 이전 서버로 접속한다면, DNS 서버 설정이 틀린 것이 아니라 클라이언트나 중간 DNS 서버가 이전 응답을 캐시에 들고 있을 수 있습니다. 그래서 DNS를 확인할 때는 브라우저 캐시, 운영체제 DNS 캐시, 공유기 캐시, DNS 서버 캐시를 구분해서 생각해야 합니다.

캐시에는 “성공한 응답”만 저장되는 것이 아닙니다. 존재하지 않는 도메인이라는 응답도 잠시 저장될 수 있습니다. 이것을 Negative Cache라고 부릅니다. 예를 들어 오타가 난 도메인을 조회해서 실패한 뒤 바로 DNS 레코드를 추가해도, 실패 결과가 잠시 남아 있으면 한동안 계속 없는 도메인처럼 보일 수 있습니다.

DNS 캐시를 볼 때 핵심 질문은 “지금 내가 보는 IP가 방금 DNS 서버에서 받은 값인가, 아니면 어딘가에 저장되어 있던 값인가?”입니다.DNS 문제를 분석할 때는 응답 IP뿐 아니라 그 응답이 캐시에서 나온 것인지도 함께 생각해야 합니다.

DNS 캐시 삭제와 재조회 — 캐시를 비운 뒤 다시 조회하면 변경된 DNS 응답을 확인하기 쉽다.

캐시 때문에 결과가 헷갈릴 때는 먼저 현재 DNS 서버가 누구인지 확인하고, 같은 도메인을 직접 지정한 DNS 서버에 물어보는 방식으로 비교합니다. 아래 명령어에서 dig @192.168.56.10처럼 DNS 서버를 직접 지정하면 “내가 원하는 DNS 서버가 실제로 어떤 응답을 주는지” 확인하기 쉽습니다.

nslookup school-login.test
dig school-login.test
dig @192.168.56.10 school-login.test

resolvectl status
resolvectl flush-caches
ipconfig /displaydns
ipconfig /flushdns

ipconfig /displaydns는 Windows가 기억하고 있는 DNS 캐시 목록을 보여 줍니다. ipconfig /flushdns는 Windows DNS 캐시를 비우는 명령입니다. Linux에서는 환경에 따라 resolvectl flush-caches로 systemd-resolved 캐시를 비울 수 있습니다.

정상 응답과 이상 응답

정상 DNS와 이상 DNS 비교 — 같은 도메인이라도 DNS 응답 IP가 달라지면 다른 서버로 접속될 수 있다.

상태	질의 도메인	응답 IP	브라우저 결과	이해 포인트
정상	school-login.test	정상 웹 서버 IP	정상 안내 페이지	이름과 목적지가 의도대로 연결됨
이상 응답	school-login.test	다른 웹 서버 IP	다른 페이지 표시	도메인은 같지만 목적지 IP가 달라짐
캐시 잔존	school-login.test	이전 응답 IP	결과 지연	TTL과 캐시를 함께 확인해야 함

정상 응답과 이상 응답을 비교할 때 가장 중요한 기준은 도메인 이름이 아니라 응답으로 받은 IP 주소입니다. 사용자는 같은 이름을 입력해도 DNS가 다른 IP를 알려주면 결국 다른 서버로 이동하게 됩니다.

핵심 개념 복습

내부 실습 도메인 구조 — 내부 학습망에서는 .test, .local 같은 테스트 도메인으로 DNS 흐름을 안전하게 익힐 수 있다.

DNS의 핵심은 “이름을 주소로 바꾸는 과정”입니다. 도메인 이름은 사람이 기억하기 좋고, IP 주소는 컴퓨터가 통신하기 좋습니다. DNS는 이 둘 사이를 연결해 주는 번역기 역할을 합니다.

A 레코드는 IPv4 주소를 알려 주고, CNAME은 다른 이름으로 연결하며, NS는 권한 있는 네임서버를 나타냅니다. TTL은 응답을 얼마나 오래 기억할지 결정합니다. 이 개념들이 합쳐져서 우리가 주소창에 입력한 이름이 실제 서버 접속으로 이어집니다.

DNS를 이해하면 웹 접속 문제를 더 잘 분석할 수 있습니다. 페이지가 안 열릴 때 서버가 꺼진 것인지, DNS가 잘못된 IP를 알려 준 것인지, 캐시 때문에 이전 결과를 보고 있는 것인지 구분할 수 있기 때문입니다.