DNS 기본기와 Route 53 운영 포인트
DNS의 계층 구조, 캐싱, TTL, Route 53 설정을 실무 관점에서 정리합니다. 특히 Alias Record, 라우팅 정책, Health Check, negative caching처럼 장애로 이어지기 쉬운 지점을 함께 짚습니다.
Script Companion
오디오와 함께 스크립트 보기
- 01
DNS는 도메인을 IP로 바꾸는 인터넷 전화번호부라는 설명에서 출발할 수 있습니다. 하지만 실무에서는 단순 변환보다 더 넓은 의미를 가집니다. AWS EC2를 재배포하거나 ALB를 교체하면 IP는 달라질 수 있지만, 도메인은 고정된 진입점으로 남습니다. DNS가 없다면 클라이언트 코드나 외부 연동 설정을 계속 바꿔야 합니다. 그래서 DNS는 로드 밸런싱, 장애 조치, A/B 테스트, 배포 없는 라우팅 변경의 시작점이 됩니다.
- 02
DNS 질의는 계층 구조로 움직입니다. 클라이언트가 api.example.com의 주소를 알고 싶다고 하면, Recursive Resolver가 대신 Root Nameserver, TLD Nameserver, Authoritative Nameserver를 차례로 찾아갑니다. Root Nameserver는 전 세계에 13개 클러스터가 있고 Anycast로 수백 개 물리 서버가 운영됩니다. TLD Nameserver는 .com, .net, .io, .kr 같은 최상위 도메인을 맡고, Authoritative Nameserver는 실제 DNS 레코드를 보유합니다. AWS Route 53은 이 Authoritative Nameserver 역할에 해당합니다.
- 03
DNS가 단일 서버가 아니라 계층 구조인 이유는 확장성과 장애 격리입니다. 단일 서버가 수억 개 도메인을 모두 관리하면 그 서버 장애가 전 세계 인터넷 장애로 이어집니다. 계층 구조에서는 Root는 TLD만 알고, TLD는 Second-Level 도메인만 알면 됩니다. Route 53이 관리하는 특정 도메인에 문제가 생겨도 다른 도메인 전체로 장애가 번지지 않습니다. 여기에 캐싱이 붙습니다. Root와 TLD 응답은 거의 변하지 않기 때문에 TTL 동안 저장되고, 두 번째 접속에서는 OS 캐시에서 바로 IP를 찾을 수 있습니다.
- 04
질의 방식은 Recursive와 Iterative를 나누어 이해하면 좋습니다. 클라이언트는 Recursive Resolver에게 최종 답만 달라고 요청하고 기다립니다. 반면 Resolver는 Root, TLD, Authoritative 서버에 반복적으로 물어보며 다음 단서를 찾아갑니다. 이 혼합 구조가 대부분의 DNS 해석 방식입니다. 내부망에서는 Private Hosted Zone도 중요합니다. db.internal 같은 이름은 외부에서 조회하면 NXDOMAIN이 나오지만, 연결된 VPC 안에서는 내부 IP가 반환됩니다. 여러 VPC에서 같은 Zone을 쓰려면 각 VPC를 모두 연결해야 합니다.
- 05
TTL, Time To Live는 DNS 응답의 캐시 유효 시간입니다. 60초 이하는 변경이 빠르지만 DNS 쿼리가 많아지고, 300초는 일반적인 API 서버에 균형점으로 쓰이며, 3600초나 86400초는 변경이 드문 리소스에 가깝습니다. 서버 마이그레이션 전에는 최소 TTL의 2배 전에 TTL을 낮춰두는 절차가 필요합니다. 응답이 있는 positive TTL과 NXDOMAIN이나 NODATA 같은 negative TTL은 별도로 동작하며, negative TTL은 SOA 레코드의 MINIMUM 필드로 제어됩니다. SOA MINIMUM이 86400이면 잠깐의 NXDOMAIN도 최대 24시간 캐시될 수 있습니다.
- 06
DNS에서 배운 TTL 기반 캐싱은 다른 시스템으로도 전이됩니다. DNS Resolver 캐시는 레코드 TTL이 0이 되면 Authoritative NS에 다시 질의합니다. CDN Edge Cache는 Cache-Control: s-maxage 또는 CDN-Cache-Control에 따라 stale 상태가 되면 Origin으로 재검증합니다. HTTP Cache-Control의 max-age=300은 브라우저가 만료 후 조건부 GET을 보내게 하고, Redis EXPIRE key 300은 TTL이 0이 되면 키를 삭제하게 합니다. 공통 트레이드오프는 같습니다. TTL이 길면 원본 부하가 줄고 응답은 빠르지만 변경 전파가 느립니다. TTL이 짧으면 최신성은 높아지지만 원본 요청이 늘어납니다.
- 07
위임 트리 구조도 다른 곳에서 다시 나타납니다. DNS의 Root, TLD, Authoritative 구조는 상위 계층이 하위 계층의 주소만 알고 실제 데이터는 리프 노드가 보유하는 설계입니다. K8s에서는 Pod의 resolv.conf가 CoreDNS로 질의를 보내고, CoreDNS가 payments 네임스페이스의 payment-svc Service ClusterIP를 반환합니다. cluster.local zone을 CoreDNS가 위임받아 관리하는 셈입니다. Consul을 함께 쓰면 CoreDNS가 consul 도메인을 Consul Agent의 8600번 포트로 포워딩합니다. DNS 위임과 유사한 원리가 서비스 디스커버리에서도 보이는 지점입니다.
- 08
레코드 타입은 역할별로 구분됩니다. A는 도메인을 IPv4로, AAAA는 IPv6로, CNAME은 다른 도메인으로 연결합니다. MX는 메일 서버, TXT는 SPF, DKIM, 도메인 소유 확인 같은 텍스트 정보, NS는 Authoritative Nameserver, SOA는 도메인 권한 정보를 담습니다. AWS에서는 Zone Apex 문제도 자주 만납니다. example.com처럼 www가 없는 존 정점에는 NS와 SOA가 반드시 존재해야 하므로 CNAME을 둘 수 없습니다. Route 53의 Alias Record는 이 제약을 피하기 위한 AWS 확장 기능이며, CloudFront, ALB, NLB, CLB, S3 정적 웹사이트 엔드포인트, API Gateway 같은 AWS 리소스에 연결할 때 사용됩니다.
- 09
Route 53 라우팅 정책은 상황별로 선택합니다. ALB 하나에 단순 연결이면 Simple, 신버전 10% 트래픽 같은 카나리 배포에는 Weighted, 멀티 리전에서는 Latency, Active-Passive 고가용성에는 Failover, 국가별 다른 콘텐츠에는 Geolocation이 맞습니다. Active-Passive는 대기 서버 비용이 적지만 Failover 때 60초에서 120초 정도 전환 지연이 있습니다. Active-Active는 여러 리소스가 동시에 트래픽을 처리하고 Weighted 또는 Latency 라우팅으로 구현합니다. 문서에서는 AWS 공식 권고로 가능하면 Active-Active를 사용하고, DNS 레코드 업데이트보다 데이터 플레인 Health Check를 활용한 자동 전환이 더 빠르고 안정적이라고 정리합니다.
- 10
장애 대응에서는 증상과 캐시 위치를 함께 봐야 합니다. 레코드를 바꿨는데 일부 네트워크만 이전 IP를 받는다면 기존 TTL 동안 Resolver가 캐시를 유지하는 DNS 전파 지연일 수 있습니다. api.example.com이 NXDOMAIN이면 Hosted Zone 도메인, 등록사의 NS 레코드, 레코드 이름 오타와 마지막 점을 확인해야 합니다. Failover가 항상 Secondary로만 간다면 Health Check가 Primary ALB를 unhealthy로 보는지, Security Group이 Route 53 Health Check IP 범위를 허용하는지, health 경로가 200을 반환하는지 점검합니다. Geolocation, Geoproximity, Latency 라우팅에서는 Default 레코드가 없으면 매핑되지 않은 지역 사용자가 응답을 받지 못할 수 있습니다. DNS 설정은 한 번 하고 잊기 쉽지만, TTL과 NS 레코드 동기화가 어긋나면 서비스 전체 장애로 이어집니다.
같은 레이어
L2에서 이어 듣기
- 오디오 파일
- /podcasts/l2-dns-basics.mp3