DNS Lookup 흐름, Recursive Resolver부터 Authoritative DNS까지
Enchantée2026. 7. 21. 08:47
728x90
반응형
브라우저 주소창에 도메인을 입력하면 애플리케이션은 곧바로 서버에 연결하는 것처럼 보입니다.
하지만 실제로는 먼저 도메인 이름을 IP address로 바꾸는 DNS Lookup 과정이 필요합니다.
이 과정은 보통 매우 빠르게 끝나지만, 장애가 나면 “서버는 살아 있는데 접속이 안 된다”, “일부 사용자만 예전 서버로 간다”, “배포 후 트래픽 전환이 예상보다 늦다” 같은 문제로 나타납니다.
오늘은 DNS Lookup이 어떤 순서로 일어나는지, Cache TTL이 왜 중요한지, 실무에서 어떤 지점을 봐야 하는지 정리해보겠습니다.
DNS Lookup은 도메인 이름을 IP address로 바꾸는 과정이고, TTL은 그 결과를 resolver와 client가 얼마나 오래 cache할 수 있는지 정하는 값입니다.
DNS는 사람이 읽기 쉬운 domain name과 network가 사용하는 IP address 사이를 연결하는 이름 해석 계층입니다.
1. DNS Lookup은 무엇인가?
DNS Lookup은 domain name을 IP address로 변환하는 과정입니다.
애플리케이션이 example.com 같은 이름으로 서버에 접속하려면, 먼저 그 이름이 어떤 IP address를 가리키는지 알아야 합니다.
이때 운영체제의 resolver, recursive resolver, root name server, TLD name server, authoritative name server가 순서대로 관여할 수 있습니다.
항상 모든 단계가 매번 실행되는 것은 아닙니다.
Cache에 이미 답이 있으면 중간 단계에서 바로 결과를 돌려줄 수 있습니다.
구성 요소
역할
실무에서 보는 지점
Stub Resolver
Client OS나 runtime이 DNS 요청을 시작
local cache, hosts file, resolver 설정
Recursive Resolver
Client 대신 DNS 계층을 따라가며 답을 찾음
ISP DNS, public DNS, VPC DNS
Root Name Server
TLD server 위치를 알려줌
com, net, kr 같은 상위 영역으로 안내
TLD Name Server
해당 domain의 authoritative server를 알려줌
등록기관, zone delegation 문제
Authoritative Name Server
실제 DNS record의 최종 답을 제공
A, AAAA, CNAME, MX, TXT record 관리
DNS는 하나의 중앙 서버가 모든 domain을 알고 있는 구조가 아닙니다.
계층적으로 위임된 name server들이 협력해 최종 record를 찾아주는 구조입니다.
2. 왜 중요한가?
DNS는 application code 밖의 문제처럼 보이지만, 실제 장애와 성능에 자주 영향을 줍니다.
첫 요청 latency, CDN 전환, blue-green deployment, 장애 조치, multi-region routing, Kubernetes service discovery 모두 이름 해석과 연결됩니다.
특히 TTL을 이해하지 못하면 DNS 변경이 즉시 반영되지 않는 이유를 설명하기 어렵습니다.
DNS cache가 있으면 매 요청마다 authoritative server까지 가지 않습니다.
TTL이 길면 query traffic은 줄지만 변경 전파가 늦어질 수 있습니다.
TTL이 짧으면 전환은 빨라지지만 resolver query가 늘어날 수 있습니다.
CNAME chain이 길면 lookup 단계와 장애 지점이 늘어날 수 있습니다.
DNS 결과가 바뀌어도 이미 열려 있는 TCP connection은 자동으로 새 IP로 바뀌지 않습니다.
실무에서는 DNS record만 바꾸고 끝내면 안 됩니다.
Client cache, resolver cache, connection pool, retry, health check까지 함께 봐야 실제 트래픽이 어떻게 이동하는지 설명할 수 있습니다.
3. 핵심 개념: TTL과 Cache
TTL은 Time To Live의 약자입니다.
DNS record를 받은 resolver가 그 답을 cache해도 되는 시간을 뜻합니다.
예를 들어 A record의 TTL이 300 seconds라면, resolver는 해당 결과를 최대 300초 동안 재사용할 수 있습니다.
이 시간 안에는 authoritative name server에 다시 묻지 않고 cache된 IP address를 반환할 수 있습니다.
TTL 설정
장점
주의할 점
긴 TTL
DNS query 감소, resolver cache 효율 증가
IP 변경, 장애 조치, 배포 전환 반영이 늦을 수 있음
짧은 TTL
record 변경 반영이 비교적 빠름
DNS query 증가, resolver와 authoritative server 부담 증가
너무 짧은 TTL
빠른 전환을 기대할 수 있음
일부 resolver가 최소 TTL을 적용하거나 application cache가 별도로 동작할 수 있음
TTL은 “이 시간이 지나면 모든 사용자가 새 IP를 본다”는 보장이 아닙니다.
Resolver 구현, client runtime, browser cache, mobile network, enterprise proxy가 중간에 별도 cache 정책을 가질 수 있습니다.
그래서 DNS 전환은 보통 TTL보다 조금 더 보수적으로 관찰해야 합니다.
4. 그림으로 이해하기
DNS Lookup과 Cache TTL 흐름을 단순화하면 다음처럼 볼 수 있습니다.
처음 조회에서는 DNS 계층을 따라가며 authoritative answer를 찾고, 이후 TTL 안에서는 resolver cache가 같은 답을 빠르게 반환할 수 있습니다.
첫 lookup은 여러 단계를 거칠 수 있지만, 한 번 답을 얻은 뒤에는 cache가 큰 역할을 합니다.
Client나 recursive resolver가 cache hit를 얻으면 root, TLD, authoritative server까지 가지 않아도 됩니다.
반대로 TTL이 만료되면 resolver는 다시 authoritative path를 통해 최신 답을 확인해야 합니다.
5. 실무 예시: 배포 전 DNS 전환
서비스를 새 load balancer나 새 region으로 옮길 때 DNS record를 바꾸는 경우가 많습니다.
이때 TTL이 길게 설정되어 있으면 일부 resolver는 기존 IP address를 계속 반환할 수 있습니다.
그래서 중요한 전환 전에는 TTL을 미리 낮추고, 충분히 기다린 뒤 record를 바꾸는 절차를 잡기도 합니다.
상태 변화
전환 1일 전
TTL을 3600 seconds에서 300 seconds로 낮춤
전환 시점
A record를 old IP에서 new IP로 변경
전환 직후
일부 resolver는 아직 old IP를 반환할 수 있음
새로 조회하거나 TTL이 만료된 resolver는 new IP를 반환
관찰 기간
old IP 트래픽이 충분히 줄어드는지 access log와 load balancer metric 확인
여기서 핵심은 DNS 변경과 실제 traffic migration이 같은 순간에 일어나지 않는다는 점입니다.
또한 DNS 결과가 새 IP로 바뀌어도 기존 keep-alive connection이나 connection pool은 old server에 남아 있을 수 있습니다.
따라서 DNS 전환 계획에는 old endpoint 유지 시간, draining, health check, rollback 기준이 함께 들어가야 합니다.
6. 네트워크와 운영체제 관점에서 보기
DNS Lookup은 application, OS, network가 만나는 지점입니다.
Application은 보통 domain name만 넘기지만, 실제 이름 해석은 OS resolver 설정과 runtime library를 통해 처리됩니다.
Container 환경에서는 host의 resolver 설정, Kubernetes DNS, VPC DNS, service mesh 설정도 함께 영향을 줄 수 있습니다.
계층
확인할 것
문제가 되는 경우
Application
DNS cache, connection pool, retry 정책
새 IP를 받아도 기존 connection을 계속 사용
OS Resolver
resolver 설정, hosts file, local cache
예상과 다른 DNS server에 질의
Recursive Resolver
cache TTL, negative caching, response policy
일부 사용자만 다른 답을 받음
Authoritative DNS
record, delegation, zone serial, health check
최종 답 자체가 잘못되거나 region별 답이 다름
Network
UDP/TCP 53, firewall, DoH, split-horizon DNS
사내망과 외부망에서 결과가 다름
DNS 장애를 볼 때는 “도메인이 안 된다”에서 멈추면 원인을 좁히기 어렵습니다.
어떤 resolver에 물었는지, cache hit인지, authoritative answer가 맞는지, 실제 connection이 어느 IP로 열렸는지 단계별로 나눠 봐야 합니다.
7. 자주 하는 오해
DNS record를 바꾸면 모든 사용자가 즉시 새 IP로 간다. Resolver와 client cache 때문에 일정 시간 동안 old IP와 new IP가 함께 관찰될 수 있습니다.
TTL을 0으로 두면 cache 문제가 사라진다. 일부 resolver는 최소 TTL을 적용할 수 있고, application이나 OS가 별도 cache를 가질 수 있습니다. Query 증가 비용도 고려해야 합니다.
DNS Lookup이 끝나면 이후 요청은 항상 같은 IP로 간다. Load balancing, multiple A records, DNS-based routing, connection pool 정책에 따라 요청이 다른 IP로 갈 수 있습니다.
CNAME은 단순한 별칭이라 비용이 없다. CNAME chain이 길면 추가 lookup이 필요하고, chain 중간의 record나 provider 장애가 영향을 줄 수 있습니다.
서버가 살아 있으면 DNS 문제는 아니다. Authoritative DNS, recursive resolver, delegation, firewall, local resolver 설정이 잘못되면 서버가 정상이어도 사용자는 접속하지 못할 수 있습니다.
DNS는 단순한 이름표가 아니라 cache와 위임이 결합된 distributed system입니다.
그래서 변경 전파와 장애 분석에서는 시간을 두고 관찰하는 태도가 필요합니다.
8. 면접 질문 예시
DNS는 네트워크 기초와 실무 장애 대응 감각을 함께 묻기 좋은 주제입니다.
브라우저에 domain을 입력했을 때 DNS Lookup은 어떤 순서로 일어나나요? Client cache, OS resolver, recursive resolver, root, TLD, authoritative name server 순서로 설명하고, cache hit가 있으면 일부 단계가 생략될 수 있다고 말하면 좋습니다.
TTL은 무엇이고 왜 중요한가요? DNS 응답을 cache할 수 있는 시간을 뜻합니다. 긴 TTL은 query를 줄이지만 변경 반영이 늦고, 짧은 TTL은 전환은 빠르지만 query 부담이 늘 수 있습니다.
DNS record를 바꿨는데 일부 사용자만 예전 서버로 접속하는 이유는 무엇일까요? Recursive resolver나 client cache가 old answer를 TTL 동안 유지할 수 있고, 이미 열린 connection pool이 old IP를 계속 사용할 수도 있습니다.
좋은 답변은 DNS 서버 이름을 나열하는 데서 끝나지 않습니다.
Cache, TTL, connection reuse, 배포 전환, 장애 분석 순서까지 연결할 수 있어야 실무적인 답변이 됩니다.
9. 정리
DNS Lookup은 domain name을 IP address로 바꾸는 이름 해석 과정입니다.
Recursive resolver는 client 대신 DNS 계층을 따라가며 authoritative answer를 찾습니다.
TTL은 DNS 응답을 cache할 수 있는 시간이며, 성능과 변경 전파 속도 사이의 trade-off를 만듭니다.
DNS record 변경은 즉시 모든 traffic 전환을 보장하지 않으며, cache와 connection pool을 함께 봐야 합니다.
