여러분 브라우저는 example.com을 보는 순간, 바로 IP 주소를 알고 있는 게 아니에요.
TCP vs UDP - 꼼꼼한 친구와 빠른 친구는 뭐가 다를까요?에서 우리는 패킷이 TCP 나 UDP 같은 방식으로 오간다는 걸 봤어요. 근데요, 거기까지 오기 전에 먼저 해결해야 하는 문제가 하나 있었죠.
“우리는 google.com만 쳤는데, 그걸 어떻게 IP 주소로 바꿔서 찾아가죠?”
맞아요. 사람은 이름을 기억하고, 컴퓨터는 숫자를 더 좋아해요. 이 둘 사이를 통역해주는 시스템이 바로 DNS 예요.
이름은 익숙한데, 실제로 뭐 하는 친구인지는 좀 흐릿하게 느껴질 수 있죠? 근데요, 생각보다 되게 일상적인 방식으로 이해할 수 있어요.
이름을 알면 번호도 바로 알 수 있을까요?
처음 가는 가게에 전화를 걸어야 한다고 상상해볼까요? 우리는 보통 가게 이름은 기억해도, 전화번호는 잘 모르잖아요. 그래서 이렇게 하죠.- 이름을 말해요
- 누군가가 번호를 찾아줘요
- 그 번호로 실제 전화를 걸어요
example.com같은 도메인 이름을 주고- DNS가 그에 맞는 IP 주소를 찾아주고
- 브라우저가 그 IP 주소로 실제 접속해요
DNS는 실제로 뭐 하는 걸까요?
한 문장으로 말하면 이거예요. DNS는 “이 이름이 어느 주소인지” 찾아주는 인터넷 주소록 시스템이에요.
근데 여기서 중요한 반전 하나.
DNS가 웹사이트를 “보내주는” 건 아니에요.DNS는 어디까지나 “어디로 가야 하는지 알려주는 역할” 을 해요. 실제 데이터는 그다음에 브라우저가 해당 서버에 접속해서 받아오는 거예요.
그럼 실제로는 누구한테 물어보는 걸까요?
“이름을 주소로 바꿔준다” 는 건 알겠는데, 누구한테 물어보는지가 궁금하죠? 보통 브라우저나 운영체제는 먼저 자신이 사용할 DNS 리졸버에게 질문해요. 리졸버가 캐시에 답을 가지고 있다면 바로 돌려주고, 없다면 필요에 따라 루트 서버, TLD 서버, 권한 있는 DNS 서버를 따라가며 답을 찾아요. 복잡해 보이죠? 근데 역할을 나누면 오히려 단순해요.- 루트 서버: 어느 TLD 쪽으로 가야 하는지 안내해요
- TLD 서버: 해당 도메인의 authoritative DNS가 어디인지 안내해요
- 권한 서버: 해당 도메인의 권한 있는 DNS 레코드를 가지고 있어요
근데 왜 굳이 이렇게 여러 단계를 거쳐요?
“그냥 엄청 큰 주소록 하나 두면 안 되나?” 싶죠? 사실은 아니에요. 여러 단계로 나누는 데는 이유가 있어요.1. 인터넷은 너무 커서 한 군데가 다 알 수 없어요
전 세계 사이트 이름을 한 서버가 전부 들고 있다면 어떨까요?- 너무 무겁고
- 너무 바쁘고
- 고장 나면 다 같이 멈춰요
2. 자주 찾는 이름은 저장해두면 빨라요
여러분도 친구 번호를 한번 찾고 나면, 다음엔 다시 검색 안 하잖아요. DNS도 그래요. 한번 찾은 결과를 캐시에 잠깐 저장해둬요. 그래서 같은 사이트는 두 번째부터 더 빨라 보일 수 있어요. 매번 처음부터 다 물어보는 게 아니거든요.3. 주소는 바뀔 수도 있으니까요
사이트가 서버를 옮기거나, 더 빠른 서버로 연결 대상을 바꾸는 경우도 있어요. 그러면 예전 주소를 영원히 들고 있으면 안 되겠죠. 그래서 DNS 캐시에는 유통기한 같은 시간이 붙어요. 그게 바로 TTL 이에요.TTL은 왜 중요할까요?
TTL은 Time To Live의 줄임말이에요. 여기서는 쉽게 말해서 “이 답을 몇 초 동안 믿고 있어도 되는지” 정도로 이해하면 충분해요. 예를 들어 TTL이 300초라면:- DNS가 주소를 알려줘요
- 컴퓨터나 DNS 서버가 그 답을 5분 동안 기억해요
- 5분이 지나면 다시 물어봐요
- 너무 길면: 주소가 바뀌었는데 예전 값을 오래 믿을 수 있어요
- 너무 짧으면: DNS 질의 빈도와 캐시 미스가 늘어날 수 있어요
즉, 빠름과 최신 정보 사이의 줄다리기인 셈이죠.
브라우저가 사이트에 접속할 때마다 항상 루트 서버부터 다시 묻는 건 아니에요. 보통은 이미 저장된 캐시 덕분에 훨씬 짧게 끝나요.참고로 이 TTL은 IP 패킷의 TTL과 이름만 같아요. DNS TTL은 캐시를 얼마나 오래 유지할지, IP TTL은 패킷이 몇 홉까지 갈 수 있는지를 뜻해요.
그럼 진짜 DNS 응답은 어떻게 생겼을까요?
실제로는 DNS도 꽤 많은 정보를 주고받아요. 근데 초반엔 이렇게 단순하게 봐도 충분해요. 여기서A 레코드는 “이 이름의 IPv4 주소 알려줘” 라는 뜻이에요. 나중에 IPv6 이야기를 하게 되면 AAAA 같은 것도 보게 되겠지만, 지금은 이름 → 주소 흐름만 잡으면 충분해요.
더 깊게 보고 싶다면 관심 있는 장면부터 골라가면 돼요. 패킷 안의 칸은 DNS 메시지는 왜 질문 하나에 칸이 이렇게 많을까요?, 터미널 출력은 dig 출력은 어디부터 읽어야 할까요?, 리졸버가 대신 여러 서버를 찾아가는 과정은 DNS 재귀 조회와 반복 조회는 뭐가 다를까요?에서 이어서 볼 수 있어요.
자, 정리해볼까요?
- DNS 는 사람이 기억하는 도메인 이름을 컴퓨터가 이해하는 IP 주소로 바꿔줘요.
- DNS는 한 서버가 다 아는 게 아니라, 여러 단계가 다음 물어볼 곳을 이어주는 구조예요.
- 자주 찾는 결과는 캐시에 저장해서 더 빠르게 답할 수 있어요.
- TTL 은 그 캐시를 얼마나 믿어도 되는지 정해주는 시간이에요.
- DNS는 데이터를 보내는 시스템이 아니라, 어디로 가야 하는지 알려주는 시스템이에요.
google.com 같은 이름을 입력할 때, 뒤에서 누가 바쁘게 주소를 찾아주고 있다는 느낌이 좀 오죠?
이제 우리는 “어느 컴퓨터로 가야 하는지”는 알게 됐어요. 근데요, 거기서 또 다음 질문이 생겨요.
다음 글 예고
컴퓨터 하나에는 웹브라우저도 있고, 게임도 있고, 메신저도 있잖아요?“그럼 같은 컴퓨터에 도착한 데이터는, 정확히 어떤 앱한테 가야 하는 건 어떻게 구분하죠?”다음 글에서는 “포트와 소켓” 이야기를 해볼게요. 같은 집에 도착한 택배를 어느 방으로 보내야 하는지, 그 규칙을 같이 살펴봐요.