우아한테크코스 테코톡
하루의 DNS
https://youtu.be/ro4CEM6IGQM?si=emIcWFigensDyV9G
하루의 DNS
- 하루의 DNS
DNS: 우리가 입력한 도메인은 어떻게 IP로 변환될까
브라우저 주소창에 google.com 같은 도메인을 입력하면 자연스럽게 페이지가 열린다. 그런데 실제 네트워크 통신은 문자열이 아니라 IP 주소로 이루어진다.
그렇다면 질문이 생긴다.
“도메인 이름은 어떻게 IP 주소로 바뀌는 걸까?”
이 과정을 담당하는 것이 바로 DNS(Domain Name System)이다. DNS는 사람이 읽기 쉬운 도메인을 컴퓨터가 이해할 수 있는 IP 주소로 변환하는 시스템이다.
이 글에서는 DNS의 구조 → 동작 흐름 → 레코드까지 실무 관점에서 정리한다.
도메인 구조: 오른쪽에서 왼쪽으로 읽어라
도메인은 단순한 문자열이 아니라 계층 구조를 가진다.
예: tech.blog.example.com
이 도메인은 점(.) 기준으로 나뉘며, 오른쪽 → 왼쪽으로 갈수록 더 구체적인 영역을 의미한다.
구조를 보면 다음과 같다.
.→ 루트 도메인 (생략됨)com→ TLD (Top-Level Domain)example→ SLD (Second-Level Domain)blog,tech→ 서브 도메인
루트 도메인은 항상 존재하지만 일반적으로 생략된다. TLD는 .com, .kr, .net 같은 최상위 도메인이고, SLD는 기업이나 서비스가 직접 등록하는 이름이다.
이 구조의 핵심은 하나다.
“도메인은 계층적으로 관리된다.”
DNS는 왜 계층 구조일까
전 세계 도메인을 하나의 서버에서 관리하는 것은 불가능하다. 그래서 DNS는 계층 구조 + 분산 시스템으로 설계되어 있다.
각 계층은 서로 다른 서버(네임 서버)가 담당한다.
구성은 다음과 같다.
1. 루트 네임 서버
- 최상위 계층
- TLD 서버의 위치를 알려줌
- 전 세계 13개 그룹 + 수백 대 서버로 구성
- 애니캐스트로 가까운 서버가 응답
2. TLD 네임 서버
.com,.kr같은 도메인 담당- SLD 네임 서버 위치를 알려줌
3. SLD 네임 서버 (권한 있는 서버)
- 실제 IP 주소를 가지고 있음
- Route53, 가비아 같은 곳에서 관리
이 구조 덕분에 DNS는 확장성과 안정성을 동시에 확보한다.
DNS 동작 흐름: 재귀적 네임 서버의 역할
DNS의 핵심은 “누가 대신 찾아주느냐”다.
사용자는 루트, TLD, SLD 서버를 하나씩 조회하지 않는다. 대신 재귀적 네임 서버(Recursive DNS)가 모든 과정을 대신 처리한다.
보통 통신사(SK, KT 등)가 제공한다.
전체 흐름
- 클라이언트 → 재귀 DNS 요청
- 캐시 확인
- 없으면 루트 → TLD → SLD 순으로 조회
- 최종 IP 반환
실제 조회 과정 (Step-by-Step)
예: example.com 요청
1. 캐시 확인
재귀 DNS는 먼저 캐시를 확인한다.
- 있으면 → 즉시 반환
- 없으면 → 다음 단계
2. 루트 서버 조회
루트 서버는 IP를 모른다.
→ 대신 .com TLD 서버 주소를 반환한다.
3. TLD 서버 조회
TLD 서버는 IP를 모른다.
→ 대신 example.com의 SLD 서버 주소를 반환한다.
4. SLD 서버 조회
SLD 서버는 실제 IP를 알고 있다.
→ 최종 IP 반환
5. 클라이언트 응답
재귀 DNS → 클라이언트에게 IP 전달
왜 “재귀적”이라고 부를까
사용자는 한 번만 요청했는데, 내부에서는 계속 질의가 반복된다.
이 과정을 재귀적 네임 서버가 대신 수행하기 때문에 Recursive(재귀적)라는 이름이 붙는다.
핵심은 이것이다.
“사용자는 한 번 요청하지만, DNS는 여러 번 질의한다.”
DNS 레코드: 어떤 값을 반환할지 정의하는 규칙
DNS 서버는 항상 IP만 반환하는 것이 아니다.
“어떤 값을 반환할지”를 정의한 데이터가 바로 레코드(Record)다.
1. A 레코드: 도메인 → IP
가장 기본적인 레코드다.
example.com → 1.2.3.4
도메인을 IPv4 주소로 매핑한다.
2. CNAME: 도메인 → 도메인
별칭(alias) 레코드다.
a.com → b.com
b.com → 1.2.3.4
결과적으로:
a.com → 1.2.3.4
이 방식의 핵심 장점은 두 가지다.
1. 관리 편의성
여러 도메인이 하나의 IP를 바라볼 때 A 레코드 하나만 변경하면 된다.
2. IP 변경 대응
CDN, 로드밸런서 환경에서는 IP가 자주 바뀐다.
CNAME을 사용하면 IP 변경을 신경 쓸 필요가 없다.
3. TTL: 캐시 전략의 핵심
TTL(Time To Live)은 캐시 유지 시간이다.
- TTL 높음 → 빠름, 변경 반영 느림
- TTL 낮음 → 느림, 변경 반영 빠름
실무에서는 이렇게 운영한다.
- 배포 전: TTL 낮춤
- 변경 후: TTL 다시 높임
DNS에서 진짜 중요한 포인트
DNS를 단순히 “도메인 → IP 변환”으로 이해하면 반쪽짜리다.
진짜 중요한 포인트는 다음 3가지다.
1. 캐시가 성능의 핵심
DNS 속도 대부분은 캐시에서 결정된다.
→ TTL 전략이 곧 성능 전략이다
2. DNS는 분산 시스템이다
루트 → TLD → SLD
→ 계층적 분산 구조
3. 장애 원인은 애플리케이션이 아닐 수도 있다
발표에서도 강조한 포인트다.
DNS를 이해하면 문제의 원인을 인프라까지 확장해서 볼 수 있다.
마무리
DNS는 단순한 변환기가 아니다. 인터넷 전체를 지탱하는 분산 시스템이다.
정리하면 핵심은 이렇다.
- DNS는 도메인을 IP로 변환한다
- 계층 구조 (루트 → TLD → SLD)로 동작한다
- 재귀 DNS가 모든 질의를 대신 수행한다
- 레코드(A, CNAME)가 반환 값을 결정한다
- TTL은 캐시 전략의 핵심이다
그리고 가장 중요한 한 줄은 이것이다.
“DNS를 이해하면, 문제를 애플리케이션이 아닌 인프라 관점에서도 볼 수 있다.”
