DNS란 무엇이고, 왜 필요한가?
DNS(Domain Name System)는
사람이 읽을 수 있는 도메인 이름을 컴퓨터가 이해하는 IP 주소로 변환해주는 시스템이다.
예를 들어,
인터넷 통신은 결국 IP 주소로 이루어지지만,
DNS 덕분에 우리는 IP를 외우지 않고도 서비스를 이용할 수 있다.
DNS 조회 과정 (Domain Name Resolution)
브라우저에 www.example.com을 입력했을 때 실제로 일어나는 일을 순서대로 살펴보자.
인터넷 주소창에 도메인을 입력했을 때, 사용자가 원하는 웹 사이트로 연결되기까지는 보이지 않는 곳에서 수많은 통신 과정이 일어납니다. 이번 포스팅에서는 도메인 이름을 IP 주소로 변환하는 DNS(Domain Name System)의 전체 구동 과정과 성능 최적화의 핵심인 캐싱(Caching) 및 TTL에 대해 상세히 알아보겠습니다.
1. DNS 구동 과정
DNS 조회는 효율성을 위해 캐시를 먼저 확인하고, 없을 경우에만 외부 서버로 질의하는 순서로 진행됩니다. 전체 흐름은 다음과 같습니다.
1단계: 브라우저 캐시 확인
가장 먼저 브라우저 내부의 DNS 캐시를 확인합니다.
- 최근에 같은 도메인에 접속한 기록이 있다면 저장된 IP 주소를 즉시 반환합니다.
- 특징: 별도의 네트워크 요청이 발생하지 않으므로 가장 속도가 빠릅니다.
2단계: OS(운영체제) DNS 캐시 확인
브라우저에 기록이 없다면, 시스템 호출(System Call)을 통해 운영체제에 질의합니다.
- Windows의 경우 DNS Client Cache, macOS/Linux의 경우 systemd-resolved 등의 데몬이 담당합니다.
- 운영체제의 hosts 파일 설정도 이 단계에서 확인합니다.
3단계: 로컬 DNS 서버(Recursive Resolver) 요청
운영체제 캐시에도 정보가 없다면, 비로소 외부 네트워크 통신이 발생합니다.
- 사용자가 연결된 인터넷 회선(ISP)에서 제공하는 DNS 혹은 사용자가 직접 설정한 공용 DNS(8.8.8.8, 1.1.1.1 등)로 요청이 전달됩니다.
- 이 서버를 로컬 DNS 또는 **리졸버(Resolver)**라고 부르며, 클라이언트를 대신해 IP를 찾아오는 역할을 수행합니다.
4단계: Root DNS 서버 조회
로컬 DNS 서버에도 캐시 데이터가 없다면, 전 세계 DNS의 최상위인 Root DNS 서버('.')에 질의합니다.
- Root 서버는 도메인의 전체 IP를 알려주는 것이 아니라, .com, .net 같은 최상위 도메인을 관리하는 서버의 위치 정보를 반환합니다.
- 응답 예시: ".com을 관리하는 TLD 서버의 주소는 여기입니다."
5단계: TLD DNS 서버 조회
로컬 DNS는 안내받은 TLD(Top-Level Domain) 서버에 다시 질의를 보냅니다.
- .com, .kr, .org 등을 관리하는 서버입니다.
- 응답 예시: "example.com 도메인의 권한을 가진 네임 서버(Authoritative Server)의 주소는 여기입니다."
6단계: Authoritative DNS 서버 조회 (최종)
마지막으로 도메인의 실제 관리 권한을 가진 Authoritative DNS 서버에 질의합니다.
- AWS Route53, 가비아, 후이즈 등 도메인을 구매하고 관리하는 곳의 네임 서버가 이에 해당합니다.
- 응답 예시: "www.example.com의 실제 IP 주소는 93.184.216.34입니다."
7단계: 응답 캐싱 및 결과 전달
최종 IP를 확보한 로컬 DNS 서버는 이 값을 자신의 캐시에 저장(TTL 시간만큼)한 뒤, 사용자 PC(브라우저)에 전달합니다. 브라우저는 받아온 IP를 통해 웹 서버에 HTTP/HTTPS 요청을 보냅니다.
2. DNS 캐싱(Caching)이 필요한 이유
DNS 조회 과정은 위에서 본 것처럼 여러 단계의 서버를 거쳐야 합니다. 만약 매 접속마다 이 과정을 반복한다면 네트워크 지연(Latency)이 발생하여 웹 서핑 속도가 현저히 느려질 것입니다.
이를 방지하기 위해 DNS는 캐싱을 전제로 설계된 시스템입니다. 한 번 조회한 정보는 아래의 여러 계층에 분산 저장되어 재사용됩니다.
- 브라우저: 가장 빠르고 즉각적인 응답
- 운영체제: 브라우저 간 공유되는 캐시 영역
- 로컬 DNS 서버: 같은 네트워크/ISP 사용자들 간에 공유되는 캐시
3. TTL(Time To Live)의 개념과 전략
캐싱은 속도를 높여주지만, IP 주소가 변경되었을 때 즉시 반영되지 않는 문제를 야기할 수 있습니다. 이를 제어하기 위한 장치가 바로 **TTL(Time To Live)**입니다.
TTL이란?
DNS 응답 결과(IP 주소 등)를 얼마나 오랫동안 캐시에 저장해도 되는지를 초(Seconds) 단위로 지정한 값입니다.
- 예시: example.com A 93.184.216.34 (TTL = 300)
- 해석: 300초(5분) 동안은 다시 물어보지 말고 저장된 IP를 사용하라.
TTL 장단점 비교
| 구분 | TTL이 길 때 | TTL이 짧을 때 |
| 장점 | DNS 요청 수 감소 사용자 응답 속도 향상 서버 부하 감소 |
IP 변경 시 빠른 전파 가능 서버 장애 시 유연한 대처(Failover) 유리 |
| 단점 | IP 변경 시 전파 속도가 느림 과거 IP로 접속되는 문제 발생 가능 |
DNS 질의량 폭증 네트워크 비용 및 로컬 DNS 부하 증가 |
실무에서의 TTL 설정 전략
서비스의 성격과 상황에 따라 적절한 TTL 값을 설정하는 것이 중요합니다.
- 일반적인 웹 서비스 (300 ~ 3600초)
- IP 변경이 잦지 않은 일반적인 상황에서는 5분에서 1시간 정도로 설정하여 쿼리 비용을 절감합니다.
- 장애 대비 / 배포 직전 (30 ~ 60초)
- 서버 마이그레이션이나 중요 업데이트를 앞두고 있다면, 변경 사항이 빠르게 전파되도록 TTL을 미리 1분 내외로 줄여놓습니다.
- CDN 및 글로벌 서비스 (가변적)
- GSLB(Global Server Load Balancing) 등을 사용하는 경우 상황에 따라 매우 짧은 TTL을 사용하기도 합니다.
'컴퓨터 네트워크' 카테고리의 다른 글
| 네트워크 exception (0) | 2024.12.24 |
|---|---|
| Network program - 2 (0) | 2024.12.24 |
| Network program (0) | 2024.12.24 |
| 네트워크 - 기본 이론 (2) | 2024.12.24 |
| InputStream, OutputStream (1) | 2024.12.22 |