base

DNS

웹 브라우저에서 www.example.com과 같은 주소를 입력했을 때, 실제로는 해당 도메인 이름에 연결된 서버의 IP 주소를 찾아야 합니다. 이때 동작하는 시스템이 바로 **DNS(Domain Name System)**입니다. DNS는 인터넷의 전화번호부와 같으며, 사람이 기억하기 쉬운 도메인 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환해주는 핵심 인프라입니다. 오늘날 대부분의 웹 서비스는 DNS 없이는 제대로 작동하지 않습니다.


DNS가 필요한 이유

인터넷은 IP 주소 기반으로 동작하지만, 사람은 숫자보다는 이름을 기억하는 데 능숙합니다. 예를 들어, 사용자가 google.com을 입력하면 실제로는 142.250.206.14와 같은 IP 주소에 연결됩니다. DNS는 이런 도메인 이름과 IP 주소 사이의 자동 변환을 담당합니다. 덕분에 우리는 복잡한 숫자열을 외우지 않고도 원하는 사이트에 접속할 수 있습니다.


뿐만 아니라 DNS는 로드 밸런싱, CDN 경로 분기, 다중 리전 서비스 분산, 장애 대응 등 다양한 인프라 전략의 기반이 됩니다. DNS가 없으면 이러한 고도화된 서비스 전략 역시 구현하기 어렵습니다.


DNS의 동작 흐름

DNS는 단순히 요청을 한 번 보내고 끝나는 것이 아니라, 여러 단계의 조회 과정을 거쳐 최종 IP 주소를 반환합니다.

1. 브라우저 캐시 확인

사용자가 이전에 방문한 도메인이라면, 브라우저가 해당 도메인의 IP 주소를 메모리에 저장해두고 있으므로 서버 요청 없이 바로 응답할 수 있습니다.

2. 운영체제 DNS 캐시 확인

브라우저에 정보가 없다면, 운영체제 수준의 DNS 캐시에서 IP 주소를 확인합니다.

3. 로컬 DNS 리졸버 질의

로컬 네트워크 또는 ISP가 제공하는 DNS 서버에 질의하여 해당 도메인의 IP 정보를 요청합니다. 이 과정에서 해당 리졸버가 캐시를 갖고 있다면 그 결과를 바로 반환합니다.

4. 루트 → TLD → 권한 있는 네임서버 질의

로컬 DNS 리졸버에 캐시가 없으면, 루트 네임서버부터 시작하여 .com TLD 네임서버, 그리고 example.com의 권한 있는 네임서버까지 순차적으로 질의하며 IP 주소를 추적합니다.

5. 응답 결과 캐싱

최종 IP 주소가 확인되면, 그 결과는 브라우저, 운영체제, 로컬 리졸버에 각각 일정 시간 동안 저장되어 이후 요청 시 빠른 응답을 가능하게 합니다.


DNS 레코드

A 레코드 vs CNAME 레코드

  • A 레코드: 도메인을 실제 IP 주소에 직접 매핑합니다.
  • CNAME 레코드: 도메인을 다른 도메인에 매핑하여 간접적으로 IP를 조회합니다.

CNAME은 다수의 서브도메인을 메인 도메인으로 정리하고자 할 때 유용하지만, 루트 도메인에는 사용할 수 없습니다.

MX, TXT, NS 레코드

  • MX: 이메일 수신을 위한 메일 서버 정보를 제공합니다.
  • TXT: 도메인 인증, 보안(SPF, DKIM 등)을 위한 텍스트 정보를 전달합니다.
  • NS: 해당 도메인을 관리하는 네임서버를 지정합니다. 도메인 위임 설정 시 필수입니다.

DNS 캐싱과 TTL 이해하기

TTL(Time To Live)이란?

DNS 응답 결과는 캐시되며, TTL은 이 캐시가 유효한 시간을 의미합니다. TTL이 짧으면 변경된 정보가 빠르게 반영되지만, 트래픽이 늘어날 수 있고, TTL이 길면 트래픽은 줄지만 변경 반영이 느릴 수 있습니다. 서비스 배포 시에는 TTL을 일시적으로 줄였다가, 안정화 이후 다시 늘리는 전략이 유효합니다.


DNS 기반 로드 밸런싱 기법

라운드 로빈 방식

하나의 도메인에 여러 IP를 등록하여 요청을 분산시키는 기법입니다. DNS 서버는 순차적으로 IP를 반환하며, 간단한 로드 밸런싱 구조를 구성할 수 있습니다.

상태 기반 분산은 어려움

DNS는 기본적으로 서버의 상태를 파악하지 않고 IP를 반환합니다. 따라서 서버가 다운되어 있어도 여전히 해당 IP를 반환할 수 있으므로, 헬스 체크를 지원하는 상위 로드 밸런서와 병행하는 것이 일반적입니다.


개발자가 자주 겪는 DNS 문제와 해결법

1. 캐시 문제

IP 변경 이후에도 클라이언트 또는 중간 DNS 서버가 이전 IP를 기억하고 있어 연결되지 않는 문제가 발생할 수 있습니다. TTL을 줄이거나 DNS 캐시를 강제로 초기화해야 해결됩니다.

2. 레코드 설정 오류

A, CNAME, MX, NS 레코드를 잘못 설정하면 웹사이트 접속 불가, 이메일 발송 실패 등 치명적인 문제가 발생할 수 있습니다. 도메인 변경 시 반드시 두세 번 검토가 필요합니다.

3. 전파 지연(Propagation Delay)

DNS 정보는 전 세계 DNS 서버에 동기화되기까지 최대 48~72시간이 소요될 수 있습니다. 특히 NS 변경은 전파 시간이 가장 오래 걸리므로 운영 일정에 반영해야 합니다.

4. 사설 DNS 충돌

내부망에서 사용하는 DNS 도메인이 공용 DNS와 겹치는 경우, 외부 접근 시 충돌이나 정보 노출 문제가 발생할 수 있습니다. 내부 전용 도메인은 .internal, .corp 등으로 명확히 구분해야 합니다.


DNS 운영 실무 팁

  • 배포 전 TTL 줄이기: 빠른 반영을 위해 사전 준비
  • 다양한 리졸버에서 테스트: ISP, Cloudflare, Google DNS 등 다양한 환경에서 확인
  • dig, nslookup, host 명령어 익숙해지기: DNS 상태를 CLI로 확인할 수 있는 기본 도구들입니다.

정리

DNS(Domain Name System)는 사람이 읽기 쉬운 도메인 이름(예: www.example.com)을 컴퓨터가 통신할 때 사용하는 IP 주소(예: 93.184.216.34)로 변환해 주는 분산형 계층 구조의 데이터베이스 시스템입니다. 클라이언트는 운영체제나 애플리케이션에 내장된 재귀적 리졸버(·Resolver)를 통해 로컬 DNS 서버에 질의하고, 로컬 서버는 캐시에 저장된 결과를 먼저 확인한 뒤 없으면 루트 네임서버→TLD(최상위 도메인) 네임서버→권한 있는 네임서버의 순서로 위임(Delegation) 과정을 거쳐 최종 IP를 조회합니다. 이 과정에서 A(IPv4 주소), AAAA(IPv6 주소), CNAME(별칭), MX(메일 교환), TXT(텍스트) 등의 다양한 레코드 타입을 지원하며, DNS 응답은 주로 UDP 53번 포트를 사용하지만 응답 크기가 크거나 보안을 위해 TCP 53번 포트를 활용하기도 합니다. 또한, DNSSEC(DNS Security Extensions)을 통해 응답 위변조를 방지하고 데이터 무결성을 보장함으로써, 인터넷 서비스의 신뢰성과 안정성을 높이는 핵심 인프라 역할을 수행합니다.


참고 자료