이름을 주소로 바꾸는 DNS

왜 이름표가 필요한가

지금까지 우리는 숫자 주소로 통신했다. 클라이언트 192.168.10.10이 웹 서버 192.168.20.10으로 패킷을 보내는 길을 만들었다. 이 방식은 컴퓨터에게는 좋다. IP 주소는 목적지를 찾는 데 필요한 정보이기 때문이다.

하지만 사람에게는 불편하다. 웹 서버가 192.168.20.10인지, DNS 서버가 192.168.20.53인지 매번 외우기는 어렵다. 서버가 많아지면 더 힘들다. 그래서 사람은 web.example.local 같은 이름을 쓰고, 컴퓨터는 그 이름을 다시 IP 주소로 바꿔야 한다.

이 일을 맡는 시스템이 DNS다. DNS는 Domain Name System의 줄임말이다. 쉽게 말해 인터넷의 전화번호부다. 사람은 이름을 찾고, 전화번호부는 실제 번호를 알려 준다. DNS도 비슷하다. 사람은 도메인 이름을 입력하고, DNS는 그 이름에 해당하는 IP 주소를 알려 준다.

다만 비유는 여기까지다. 전화번호부는 보통 한 권의 책처럼 떠올리지만, 실제 DNS는 전 세계에 흩어진 여러 서버가 서로 역할을 나누어 답을 찾는 구조다. 한 서버가 모든 이름과 주소를 혼자 들고 있지 않다.

AI 생성 이미지

도메인 이름과 IP 주소의 차이

도메인 이름은 사람이 기억하기 좋게 붙인 이름이다. 예를 들어 www.example.com이나 web.example.local 같은 형태다. 왼쪽에서 오른쪽으로 갈수록 더 큰 범위의 이름이 된다.

web.example.local을 나누어 보면 다음과 같다.

• web: 특정 서버나 서비스 이름

• example: 우리가 정한 작은 영역 이름

• local: 가장 바깥쪽 이름 영역

여기서 example.local은 이 책의 작은 인터넷 안에서 쓰는 실습용 이름이라고 생각하면 된다. 실제 회사나 서비스 환경에서는 이미 정해진 내부 이름 규칙을 따르거나, 자신이 관리하는 도메인의 하위 이름을 쓰는 편이 안전하다. 특히 .local은 장비들이 같은 네트워크 안에서 서로를 자동으로 찾을 때 쓰는 mDNS 이름과 겹칠 수 있으므로, 실제 환경에서는 네트워크 정책에 맞게 이름을 정해야 한다.

반대로 IP 주소는 컴퓨터가 목적지를 찾기 위해 사용하는 숫자 주소다. 예를 들어 우리 작은 인터넷에서는 웹 서버가 192.168.20.10이다. 라우터는 이 숫자 주소를 보고 패킷을 어느 방향으로 보낼지 판단한다.

즉 역할이 다르다.

브라우저에 도메인 이름을 입력했다고 해서 패킷이 이름만 들고 이동하는 것은 아니다. 통신을 시작하기 전에 먼저 이름을 IP 주소로 바꾼다. 그다음부터는 앞에서 배운 것처럼 IP 주소와 라우팅 테이블을 따라 패킷이 이동한다.

DNS가 답을 찾아가는 방식

사용자가 브라우저에 www.example.com을 입력했다고 해 보자. 컴퓨터는 이 이름의 IP 주소를 알아야 한다. 이때 보통 컴퓨터가 직접 전 세계 DNS 서버를 모두 찾아다니지는 않는다. 대신 가까운 DNS 도우미에게 묻는다.

이 도우미를 재귀 DNS 서버라고 한다. 재귀라는 말은 어렵지만, 여기서는 "사용자 대신 끝까지 물어봐 주는 서버"라고 이해하면 된다. 사용자는 한 번만 묻고, 재귀 DNS 서버가 여러 곳을 차례로 찾아가 답을 구한다.

과정은 다음과 같다.

1. 내 컴퓨터가 재귀 DNS 서버에 묻는다.
   "www.example.com의 IP 주소가 무엇인가요?"

2. 재귀 DNS 서버가 루트 DNS 서버에 묻는다.
   루트 DNS는 전체 DNS 세계의 가장 위쪽 안내판이다. 모든 주소를 직접 알지는 않지만, .com 같은 최상위 영역을 어디에 물어봐야 하는지 알려 준다.

3. 재귀 DNS 서버가 최상위 도메인 DNS 서버에 묻는다.
   최상위 도메인은 .com, .net, .org, .kr처럼 도메인 이름의 맨 오른쪽 부분이다. 영어로는 TLD, Top-Level Domain이라고 한다. .com 담당 서버는 example.com을 누가 관리하는지 알려 준다.

4. 재귀 DNS 서버가 권한 있는 DNS 서버에 묻는다.
   권한 있는 DNS 서버는 특정 도메인의 최종 전화번호부다. example.com을 관리하는 서버라면 www.example.com의 IP 주소를 실제로 알고 있다.

5. 재귀 DNS 서버가 내 컴퓨터에 답한다.
   "www.example.com의 IP 주소는 이 주소입니다."

이 흐름을 우체국 비유로 보면 쉽다. 집배원이 모든 집 주소를 외우는 것은 아니다. 먼저 큰 지역 안내를 보고, 그다음 시·구·동 담당자를 찾아가고, 마지막으로 실제 배달 구역의 주소록을 확인한다. DNS도 큰 안내판에서 작은 담당자로 내려가며 답을 찾는다.

하지만 여기서 비유는 끝난다. 실제 DNS 조회는 사람이 서류를 넘기는 일이 아니라, 여러 DNS 서버가 정해진 형식의 작은 메시지를 주고받는 과정이다.

그리고 이 모든 단계를 매번 처음부터 거치는 것은 아니다. 이미 답을 알고 있거나, 중간 안내 정보를 기억하고 있다면 그만큼 과정을 줄일 수 있다. 이때 중요한 것이 바로 캐시다.

DNS 캐시와 TTL

DNS가 매번 루트 DNS부터 다시 물어본다면 인터넷은 느려질 것이다. 그래서 DNS는 답을 잠시 기억한다. 이것을 DNS 캐시라고 한다. 캐시는 자주 쓰는 정보를 가까운 곳에 잠시 보관하는 저장소다. 책상 위에 자주 보는 연락처를 적어 두는 것과 비슷하다.

캐시는 여러 곳에 있을 수 있다.

• 브라우저가 잠시 기억할 수 있다.

• 운영체제가 잠시 기억할 수 있다.

• 재귀 DNS 서버가 많은 사용자를 위해 기억할 수 있다.

예를 들어 재귀 DNS 서버가 방금 www.example.com의 IP 주소를 알아냈다면, 다음 사용자가 같은 이름을 물었을 때 다시 루트 DNS부터 찾아갈 필요가 없다. 저장해 둔 답을 바로 돌려줄 수 있다. 그래서 DNS 응답이 빨라진다.

그런데 캐시는 영원히 기억하면 안 된다. 서버의 IP 주소가 바뀔 수도 있기 때문이다. 그래서 DNS 답에는 TTL이 붙는다. TTL은 Time To Live의 줄임말로, "이 답을 얼마나 오래 믿어도 되는가"를 나타내는 시간이다.

TTL이 300초라면, DNS 서버나 컴퓨터는 그 답을 최대 300초 동안 캐시에 보관할 수 있다. 그 시간이 지나면 다시 물어봐야 한다.

TTL은 장점과 단점을 함께 가진다.

• TTL이 길면 같은 질문에 빠르게 답할 수 있다.

• TTL이 길면 주소를 바꿨을 때 예전 답이 오래 남을 수 있다.

• TTL이 짧으면 변경 사항이 비교적 빨리 반영된다.

• TTL이 짧으면 DNS 서버에 질문이 더 자주 간다.

그래서 DNS 변경이 바로 적용되지 않는 일이 생긴다. 서버 주소를 바꿨는데 어떤 사람은 새 주소로 가고, 어떤 사람은 아직 옛 주소로 가는 상황이 생길 수 있다. DNS가 고장 난 것이 아니라, 여러 곳에 남아 있는 캐시의 TTL이 아직 끝나지 않았을 수 있다.

작은 인터넷에 이름 붙이기

이제 우리 작은 인터넷에 DNS를 넣어 보자. 우리가 그린 작은 인터넷 설계도에서 서버 네트워크에는 두 대의 중요한 서버가 있었다.

지금까지는 클라이언트가 웹 서버에 접속하려면 192.168.20.10을 직접 사용해야 했다. 이제 여기에 이름을 붙인다.

예를 들어 다음처럼 정한다.

이 표의 한 줄을 DNS에서는 레코드라고 부른다. 레코드는 이름과 그 이름에 대한 정보를 적어 둔 항목이다. 그중 이름을 IPv4 주소로 바꾸는 레코드를 A 레코드라고 한다. 어렵게 느껴지면 "이름 → IPv4 주소"라고 적힌 전화번호부 한 줄이라고 생각하면 된다.

우리의 작은 인터넷에서는 전 세계 DNS 계층을 모두 만들 필요가 없다. DNS 서버 192.168.20.53이 example.local이라는 작은 영역의 이름표 목록을 들고 있고, 클라이언트들이 그 서버에 물어보도록 정하면 된다. 실제 인터넷의 거대한 DNS 구조를 아주 작게 줄여서 연습하는 셈이다.

작은 인터넷에서 DNS를 쓰려면 두 가지가 필요하다.

첫째, DNS 서버가 이름표 목록을 가지고 있어야 한다. DNS 서버 192.168.20.53은 web.example.local이 192.168.20.10이라는 사실을 알아야 한다.

둘째, 클라이언트가 어느 DNS 서버에 물어볼지 알아야 한다. 클라이언트 192.168.10.10의 DNS 서버 주소를 192.168.20.53으로 설정한다. 그러면 사용자가 브라우저에 web.example.local을 입력했을 때 클라이언트는 먼저 DNS 서버에 묻는다.

흐름은 이렇게 된다.

1. 사용자가 클라이언트에서 web.example.local을 입력한다.

2. 클라이언트는 DNS 서버 192.168.20.53에 질문한다.

3. 라우터 R1, R2, R3를 지나 DNS 질문이 서버 네트워크로 간다.

4. DNS 서버는 web.example.local = 192.168.20.10이라고 답한다.

5. 클라이언트는 이제 웹 서버의 IP 주소를 알게 된다.

6. 클라이언트는 192.168.20.10으로 웹 요청을 보낸다.

7. 웹 서버가 응답하고, 브라우저에 페이지가 열린다.

여기서 중요한 점이 있다. DNS는 웹 페이지를 직접 가져다주지 않는다. DNS는 "그 이름의 IP 주소가 무엇인지"만 알려 준다. 실제 웹 통신은 그다음에 일어난다. 전화번호부가 식당의 전화번호를 알려 줄 뿐, 음식을 배달하지는 않는 것과 같다.

먼저 주소로, 그다음 이름으로

작은 인터넷에서 DNS를 붙일 때는 순서가 중요하다.

먼저 숫자 IP 주소로 웹 서버에 닿는지 확인한다. 클라이언트가 192.168.20.10에 접속할 수 없다면 DNS를 고칠 단계가 아니다. 라우팅, 게이트웨이, 서버 연결을 먼저 봐야 한다.

그다음 DNS 서버에 닿는지 확인한다. 클라이언트가 192.168.20.53까지 갈 수 있어야 이름을 물어볼 수 있다. DNS 서버가 아무리 정확한 전화번호부를 가지고 있어도, 그 서버에 질문이 도착하지 않으면 답을 받을 수 없다.

마지막으로 이름이 올바른 IP 주소로 바뀌는지 확인한다. web.example.local을 물었을 때 192.168.20.10이 돌아오면 이름표는 제대로 붙은 것이다.

정리하면 순서는 이렇다.

1. 웹 서버 IP 주소로 직접 접속해 본다.

2. DNS 서버 IP 주소에 닿는지 확인한다.

3. 클라이언트의 DNS 서버 설정을 확인한다.

4. 도메인 이름이 올바른 IP 주소로 바뀌는지 확인한다.

5. 그다음 브라우저에서 이름으로 접속한다.

이 순서를 지키면 문제를 빠르게 좁힐 수 있다. 이름으로 접속이 안 된다고 해서 항상 DNS 문제는 아니다. 실제로는 웹 서버가 꺼져 있거나, 라우터의 돌아오는 길이 없거나, 클라이언트가 엉뚱한 DNS 서버에 묻고 있을 수도 있다.

DNS가 안 될 때 보는 곳

DNS 문제는 겉으로는 모두 비슷하게 보인다. 브라우저는 "사이트를 찾을 수 없다"고 말한다. 하지만 안쪽 원인은 여러 가지다.

첫째, IP 통신이 되는지 본다. DNS는 IP 네트워크 위에서 움직이는 서비스다. 아래쪽 길이 끊어져 있으면 DNS도 동작할 수 없다. 클라이언트에서 DNS 서버와 웹 서버의 IP 주소까지 닿는지 먼저 확인한다.

둘째, 클라이언트의 DNS 서버 주소를 본다. 클라이언트가 192.168.20.53이 아니라 엉뚱한 DNS 서버에 묻고 있으면, 우리 작은 인터넷의 이름표를 찾지 못한다.

셋째, DNS 서버의 레코드를 본다. web.example.local이 192.168.20.10으로 등록되어 있는지 확인한다. 숫자 하나가 틀려도 클라이언트는 다른 곳으로 가거나 아예 접속하지 못한다.

넷째, TTL과 캐시를 생각한다. 방금 레코드를 고쳤는데도 예전 주소가 나온다면, 어딘가에 남아 있는 캐시가 아직 TTL이 끝나기를 기다리고 있을 수 있다. 이때는 설정이 틀렸다고 바로 단정하지 말고, 캐시가 남아 있는지 확인한다.

다섯째, 이름의 철자를 본다. web.example.local과 www.example.local은 같은 이름이 아니다. DNS는 비슷해 보이는 이름을 알아서 맞춰 주지 않는다. 전화번호부에서 이름 한 글자가 다르면 다른 사람을 찾는 것과 같다.

DNS는 인터넷을 편하게 만드는 장치다. 하지만 마법은 아니다. 이름을 IP 주소로 바꿔 줄 뿐이고, 그다음 통신은 우리가 만든 주소, 게이트웨이, 라우팅 테이블 위에서 움직인다.

이번 장에서 작은 인터넷에는 이름표가 생겼다. 이제 사용자는 숫자 주소 대신 web.example.local을 입력할 수 있다. 다음 장에서는 이 이름으로 찾아간 뒤, 실제 데이터가 어떻게 쪼개지고 다시 맞춰지는지 살펴본다.