DNS basics

분류: Layer 2 - 인프라 기초 | 작성일: 2026-04-01

1. 한 줄 정의

DNS(Domain Name System)는 사람이 기억하는 이름(api.example.com)을 네트워크가 라우팅할 수 있는 주소(52.94.1.2)로 바꾸는 분산 이름 해석 시스템이다. 단순한 전화번호부라기보다, 누가 어떤 이름을 관리할 권한이 있는지 위임하고, 이미 확인한 답은 TTL(Time To Live) 동안 캐시하는 인터넷의 공통 조회 계층이다.

DNS를 읽을 때는 세 단어를 먼저 붙잡으면 된다.

• 이름(name): api.example.com처럼 사람이 소유권과 역할을 읽을 수 있는 문자열.
• 권한(authority): 이 이름의 정답을 말할 수 있는 서버와 zone.
• 캐시(cache): 정답 또는 “없다”는 응답을 일정 시간 재사용하는 계층.

---

2. 왜 중요한가

• IP는 바뀌어도 이름은 유지된다: ALB 교체, EC2 재배포, CloudFront 전환처럼 실제 엔드포인트가 바뀌어도 클라이언트는 같은 도메인을 호출한다.
• 트래픽 제어의 출발점이다: Weighted, Latency, Failover 같은 Route 53 정책은 HTTP 요청이 서버에 닿기 전 DNS 응답에서 먼저 방향을 정한다.
• 캐시는 성능과 장애 전파를 동시에 만든다: TTL이 길면 빠르고 싸지만 오래된 주소가 오래 남는다. TTL이 짧으면 전환은 빠르지만 resolver(클라이언트 대신 DNS를 물어보고 캐시하는 서버)와 authoritative 서버(특정 zone의 정답을 말할 권한이 있는 서버) 질의가 늘어난다.
• 보이지 않는 장애가 많다: authoritative 서버는 고쳤는데 public resolver에는 NXDOMAIN이 남아 있거나, DNSSEC 검증 실패가 SERVFAIL로만 보이는 식의 문제가 생긴다.

한 문장으로 말하면, DNS는 “이름을 주소로 바꾸는 기능”이면서 동시에 소유권 위임, 캐시 무효화, 글로벌 트래픽 라우팅을 한꺼번에 다루는 시스템이다.

---

2.5 선행 기술의 한계 — HOSTS.TXT에서 DNS가 등장한 이유

DNS 이전에는 SRI-NIC가 관리하던 단일 HOSTS.TXT 파일이 인터넷 호스트명과 주소의 정본이었다. 각 호스트가 중앙 서버에서 파일을 내려받아 로컬에 저장했고, 새 호스트가 생기면 중앙 파일을 고쳐 다시 배포했다. ARPANET 초기 수백 대 규모에서는 충분했지만, 호스트 수와 조직 수가 늘자 네 가지 문제가 동시에 커졌다.

HOSTS.TXT 한계와 DNS의 대응

분산 비용 폭증

모든 호스트가 전체 파일을 받아야 했다. 호스트가 10배 늘면 파일 크기와 다운로드 주체가 함께 늘어 배포 부하가 대략 제곱 형태로 커진다.

DNS는 필요한 이름만 질의하고, 받은 응답은 TTL 동안 캐시하게 했다.

중앙 행정 병목

작은 이름 변경도 중앙 관리자를 거쳐야 했다. 조직마다 독립적으로 이름을 운영하기 어려웠다.

DNS는 zone 단위 위임으로 각 조직이 자기 하위 이름 공간을 관리하게 했다.

평면 네임스페이스

이름이 한 평면에 놓여 충돌과 소유권 분쟁이 잦았다. 같은 이름을 누가 쓸지 중앙에서 조정해야 했다.

DNS는 `.com`, `example.com`, `api.example.com`처럼 계층형 이름 공간을 만들었다.

느린 변경 전파

호스트가 파일을 다시 내려받기 전까지 새 주소가 반영되지 않았다. 전환 속도를 이름 소유자가 조절하기 어려웠다.

DNS는 TTL 기반 캐시 만료로 변경자가 전파 속도와 조회 부하를 선택하게 했다.

이 문서의 뒤쪽에서 배우는 Root/TLD/Authoritative 위임, Route 53 Hosted Zone, TTL, negative caching은 모두 이 한계에 대한 직접적인 답이다. DNS가 없다면 api.example.com을 ALB로 보내는 것도, 장애 시 DR 리전으로 넘기는 것도, 내부 서비스 이름을 VPC 안에서만 해석하는 것도 각 클라이언트의 설정 파일 문제로 되돌아간다.

출처: RFC 1034 §2.1 — The history of domain names

---

3. 핵심 모델 — DNS는 위임된 트리를 캐시하며 걷는다

DNS 질의는 “거대한 중앙 DB에서 한 번 조회”가 아니다. Recursive resolver가 위임 트리를 따라가며 정답을 말할 권한이 있는 서버를 찾고, 그 결과를 캐시한다.

3-1. 용어 먼저 잡기

용어	뜻	처음 읽을 때의 감각
Stub resolver	OS나 애플리케이션에 있는 얇은 DNS 클라이언트	직접 Root를 돌지 않고 recursive resolver에게 맡긴다.
Recursive resolver	클라이언트 대신 Root/TLD/Authoritative를 순회하는 resolver	ISP, 회사 DNS, 8.8.8.8, 1.1.1.1이 이 역할을 한다.
Root nameserver	최상위 힌트 서버	.com, .net, .kr 같은 TLD 담당자를 알려준다.
TLD nameserver	Top-Level Domain 담당 서버	example.com의 authoritative nameserver를 알려준다.
Authoritative nameserver	특정 zone의 정답을 가진 서버	Route 53 Hosted Zone의 NS 서버가 여기에 해당한다.
Zone	한 주체가 권한을 갖고 관리하는 이름 공간	example.com zone이 api.example.com 레코드를 가질 수 있다.
Record	이름에 붙은 응답 데이터	A, AAAA, CNAME, MX, TXT, NS, SOA 등이 있다.
TTL	캐시 유효 시간	TTL이 남아 있으면 resolver는 authoritative에 다시 묻지 않는다.

Authoritative nameserver는 “항상 인터넷 전체를 아는 서버”가 아니라 자기가 위임받은 zone의 정답만 말할 수 있는 서버다. Root는 api.example.com의 IP를 모르고, TLD도 모른다. Root는 .com 담당자를, .com TLD는 example.com 담당자를, example.com authoritative만 최종 레코드를 안다.

3-2. api.example.com을 해석하는 흐름

Recursive resolver가 위임 트리를 따라가는 흐름

sequenceDiagram
participant App as 애플리케이션/브라우저
participant OS as OS Stub Resolver
participant Resolver as Recursive Resolver
participant Root as Root NS
participant TLD as .com TLD NS
participant Auth as example.com Authoritative NS

App->>OS: api.example.com 주소 요청
OS->>Resolver: 최종 답을 요청
Resolver->>Root: .com 담당은 누구인가?
Root-->>Resolver: .com TLD NS
Resolver->>TLD: example.com 담당은 누구인가?
TLD-->>Resolver: example.com NS
Resolver->>Auth: api.example.com A/AAAA 레코드?
Auth-->>Resolver: 52.94.1.2, TTL 300
Resolver-->>OS: 52.94.1.2
OS-->>App: 연결할 IP 반환

이 흐름에서 클라이언트와 resolver 사이의 요청은 recursive 질의다. 클라이언트는 “최종 답만 달라”고 맡긴다. Resolver가 Root, TLD, Authoritative에 묻는 질의는 보통 iterative 질의다. 상대가 최종 답을 모르면 다음 담당자를 알려주는 방식이다.

퀴즈

브라우저가 Root nameserver에 직접 질의하지 않는 이유는 무엇인가?

힌트: 클라이언트가 원하는 것은 위임 경로가 아니라 최종 연결 대상이다.

정답 보기

브라우저나 OS의 stub resolver는 최종 답을 recursive resolver에게 맡긴다. Root/TLD/Authoritative를 순회하고 캐시를 관리하는 책임은 recursive resolver가 갖는다.

3-3. DNS 응답은 네 구역으로 읽는다

DNS 응답을 처음 보면 A 레코드 한 줄만 찾기 쉽지만, 실제 응답은 보통 네 구역으로 나뉜다. 각 구역은 “최종 답인지, 다음 담당자 힌트인지, 추가 주소 힌트인지”를 구분하게 해 준다.

QUESTION SECTION:
api.example.com.      IN A

ANSWER SECTION:
api.example.com. 300  IN A  52.94.1.2

AUTHORITY SECTION:
example.com.     172800 IN NS ns-123.awsdns-45.com.

ADDITIONAL SECTION:
ns-123.awsdns-45.com. 172800 IN A 205.251.196.1

각 구역의 의미는 다음과 같다.

구역	의미	장애 해석에서 보는 것
Question	내가 무엇을 물었는가	이름 오타, 레코드 타입 오해
Answer	최종 답 또는 CNAME chain	기대한 A/AAAA/CNAME/TXT가 있는가
Authority	이 zone의 권한 서버 또는 부재 응답의 SOA	delegation이 어디로 이어지는가, NXDOMAIN TTL은 무엇인가
Additional	질의자가 다음 서버에 바로 갈 수 있게 주는 보조 주소	NS 이름의 IP가 같이 붙는가

Answer가 비어 있어도 항상 실패는 아니다. Root나 TLD에 물으면 최종 A 레코드 대신 Authority에 다음 NS가 올 수 있다. 반대로 authoritative에 물었는데 Answer가 비고 Authority에 SOA가 오면 “다음 담당자”가 아니라 “이 zone 기준으로 그런 이름은 없다”는 의미일 수 있다.

3-4. UDP와 TCP를 DNS 관점에서 짧게 상기하기

앞선 TCP/UDP 문서에서 본 것처럼 UDP는 연결 수립 핸드셰이크가 없고 헤더가 작다. DNS의 일반 질의는 작고 빈번하며 “이름 하나에 대한 답”을 빨리 받는 일이므로 기본적으로 UDP 53번 포트를 사용한다.

다만 DNS가 항상 UDP만 쓰는 것은 아니다.

상황	왜 TCP가 필요해지는가
응답이 UDP 한계보다 크거나 TC(truncated) 비트가 켜짐	일부 응답이 잘렸으므로 TCP로 다시 질의해야 완전한 응답을 받는다.
Zone transfer(AXFR/IXFR)	여러 레코드를 일관되게 많이 전송해야 하므로 TCP가 맞다.
DNSSEC으로 응답이 커짐	RRSIG, DNSKEY 같은 검증 데이터가 붙어 UDP 응답 크기가 커질 수 있다.
DoT/DoH 사용	DNS over TLS는 TCP/TLS, DNS over HTTPS는 HTTPS 연결 위에서 DNS 메시지를 보낸다.

따라서 DNS 장애를 볼 때 “UDP가 막혔나?”만 보면 부족하다. UDP 53이 정상이어도 큰 응답의 TCP fallback이 막히면 특정 레코드나 DNSSEC 응답만 실패할 수 있다.

---

4. 위임과 zone — 누가 정답을 말할 수 있는가

4-1. Root, TLD, Authoritative의 책임 분리

DNS 위임은 상위 계층이 하위 계층의 위치를 알려주고, 실제 레코드는 하위 계층이 관리하는 구조다.

.
└── com.
    └── example.com.
        ├── NS  ns-123.awsdns-45.com.
        ├── SOA ns-123.awsdns-45.com. awsdns-hostmaster.amazon.com. ...
        ├── A   example.com -> ALIAS CloudFront
        └── A   api.example.com -> ALIAS ALB

example.com을 Route 53으로 운영하려면 두 위치가 맞아야 한다.

1. 도메인 등록사: example.com의 NS가 Route 53 Hosted Zone의 NS로 설정되어 있어야 한다.
2. Route 53 Hosted Zone: 그 NS들이 api.example.com 같은 실제 레코드를 가지고 있어야 한다.

등록사 NS는 예전 호스팅 업체를 가리키고, Route 53 안에만 새 레코드를 만들면 authoritative 경로가 새 zone에 도달하지 못한다. 반대로 등록사 NS는 Route 53을 가리키는데 Route 53 zone 안에 레코드가 없으면 authoritative는 “없다”고 답한다.

4-2. Zone과 delegation의 작은 worked example

조직이 example.com 전체는 중앙 플랫폼 팀이 관리하고, dev.example.com은 개발 플랫폼 팀이 독립 관리하게 하고 싶다고 하자.

example.com zone
├── api.example.com      A/ALIAS -> prod ALB
├── www.example.com      A/ALIAS -> CloudFront
└── dev.example.com      NS -> ns1.dev-dns.example.net

dev.example.com zone
├── api.dev.example.com  A -> dev ALB
└── db.dev.example.com   CNAME -> dev-rds.xxxxxx.ap-northeast-2.rds.amazonaws.com

이때 dev.example.com NS ... 레코드는 “하위 zone의 정답은 저 nameserver에 물어보라”는 위임이다. 상위 zone은 하위 레코드 하나하나를 알 필요가 없다. 이 구조 덕분에 이름 공간을 조직 경계와 운영 책임에 맞게 나눌 수 있다.

4-3. Public Hosted Zone과 Private Hosted Zone

Public Hosted Zone은 인터넷의 public recursive resolver가 따라올 수 있는 zone이다. www.example.com, api.example.com, example.com 같은 외부 사용자용 이름을 둔다.

Private Hosted Zone은 VPC 내부 resolver에서만 해석되는 zone이다. 같은 이름을 VPC 밖에서 물으면 NXDOMAIN이거나 다른 public zone의 응답이 나올 수 있다.

외부 public resolver:
db.internal.example.com -> NXDOMAIN

VPC 내부 resolver:
db.internal.example.com -> 10.0.21.5

Private Hosted Zone의 핵심은 “보안 기능”이 아니라 이름 해석 범위 제한이다. 인터넷에서 내부 IP를 숨기는 효과는 있지만, 권한 제어는 Security Group, NACL, IAM, 데이터베이스 인증이 담당해야 한다.

4-4. Split-horizon DNS의 반례

같은 이름이 내부와 외부에서 다르게 해석되는 구성을 split-horizon DNS라고 한다.

public:
api.example.com -> 203.0.113.10

private VPC:
api.example.com -> 10.0.12.34

이 방식은 내부 트래픽을 private IP로 보내 비용과 지연을 줄일 수 있지만, 디버깅을 어렵게 만든다. 개발자가 노트북에서 확인한 IP와 ECS task 안에서 확인한 IP가 다르면 둘 중 하나가 틀린 것이 아니라 resolver 위치가 다른 것이다. DNS 문제를 볼 때는 항상 “어디에서 물었는가”를 같이 기록해야 한다.

---

5. 캐싱과 TTL — 빠르게 만들수록 오래 남는다

DNS 성능은 캐싱 없이는 성립하지 않는다. 매 요청마다 Root부터 Authoritative까지 순회한다면 작은 API 호출 하나에도 글로벌 nameserver 순회 비용이 붙는다. DNS는 여러 계층에서 응답을 저장한다.

DNS 캐시 miss가 다음 계층으로 내려가는 흐름

flowchart TD
Browser["브라우저 캐시"] -->|"miss"| OS["OS DNS 캐시"]
OS -->|"miss"| Resolver["Recursive Resolver 캐시"]
Resolver -->|"miss"| Root["Root Nameserver"]
Root --> TLD["TLD Nameserver"]
TLD --> Auth["Authoritative Nameserver"]
Auth --> Resolver
Resolver --> OS
OS --> Browser

5-1. Positive TTL

Positive TTL은 A, AAAA, CNAME 같은 존재하는 응답의 캐시 유효 시간이다.

api.example.com.  300  IN  A  52.94.1.2
                  └── TTL 300초

TTL 300초는 “앞으로 5분 동안 이 resolver는 authoritative에 다시 묻지 않고 같은 답을 줄 수 있다”는 뜻이다. TTL이 0이 되면 다음 질의 때 authoritative에 다시 확인한다.

TTL 값 선택 기준

60초 이하

전환은 빠르지만 resolver 캐시 효율이 낮아지고 query 비용과 authoritative 부하가 늘어난다.

장애 조치, 점진 전환, 마이그레이션 직전처럼 빠른 반영이 더 중요할 때

300초

변경 속도와 캐시 효율의 균형점이다. 운영 중인 API 레코드에서 자주 쓰인다.

일반적인 ALB Alias, API 서버, 자주 바뀌지는 않지만 전환 가능성이 있는 레코드

3600초

조회 부하를 줄이지만 잘못된 주소도 한 시간 가까이 남을 수 있다.

변경이 드문 정적 이름, 내부 시스템에서 변경 창이 충분히 긴 레코드

86400초

하루 동안 캐시될 수 있다. 긴급 전환 대상에는 부적합하다.

거의 변하지 않는 위임 정보처럼 안정성이 매우 높은 항목

5-2. TTL 수치 감각

TTL을 300초로 둔 api.example.com에 한 recursive resolver 뒤의 클라이언트 10,000명이 1분 동안 접근한다고 하자. 첫 사용자가 질의해 응답을 캐시하면, 같은 resolver를 쓰는 나머지 사용자는 5분 동안 authoritative에 새로 묻지 않는다. 애플리케이션 요청은 10,000번이어도 authoritative DNS 질의는 1번에 가까워질 수 있다.

반대로 TTL을 30초로 낮추면 변경 전파는 빨라지지만 같은 5분 동안 resolver가 최대 10번 정도 authoritative에 다시 물을 수 있다. DNS 비용과 authoritative 부하뿐 아니라, 장애 상황에서 authoritative가 느려질 때 사용자 지연도 더 자주 드러난다.

TTL 선택은 “낮을수록 좋다”가 아니다.

목표	TTL 방향	대가
빠른 장애 전환	낮춘다	query 증가, 캐시 효율 하락
비용과 부하 절감	높인다	오래된 주소가 오래 남음
마이그레이션 안정성	전환 전에 낮추고, 안정 후 올린다	계획 시간이 필요함
내부 서비스 안정성	중간값부터 시작한다	너무 낮으면 내부 resolver가 병목이 될 수 있음

5-3. 마이그레이션 worked example

api.example.com이 Old ALB를 가리키고 있고 TTL이 3600초라고 하자. 10:00에 New ALB로 바꾸면 모든 사용자가 즉시 새 ALB로 가지 않는다. 09:59에 Old ALB 응답을 캐시한 resolver는 10:59까지 이전 응답을 줄 수 있다.

안전한 전환은 보통 이렇게 잡는다.

T-2h: TTL 3600 -> 60으로 낮춘다.
T-1h: 기존 3600초 캐시가 대부분 만료될 시간을 기다린다.
T:    ALB Alias 대상을 New ALB로 바꾼다.
T+10m: public resolver와 주요 지역에서 새 응답 비율을 확인한다.
T+1d: 안정화 후 TTL을 300 또는 3600으로 되돌린다.

“TTL을 낮췄는데 왜 바로 안 바뀌지?”라는 질문의 답은 이미 배포된 이전 TTL에 있다. TTL 변경 자체도 DNS 응답이므로, 이미 3600초로 캐시된 resolver에는 그 캐시가 만료되기 전까지 새 TTL이 보이지 않는다.

5-4. Negative TTL과 NXDOMAIN 캐싱

Negative TTL은 NXDOMAIN이나 NODATA처럼 존재하지 않는다는 응답의 캐시 유효 시간이다. DNS에서 “없다”도 응답이고, resolver는 그 응답도 캐시한다.

RFC 2308은 negative caching을 SOA 레코드의 TTL과 MINIMUM 값을 바탕으로 다룬다. 실무에서 중요한 감각은 단순하다. 잠깐의 오타나 zone 미배포로 NXDOMAIN이 나가면, 일부 resolver는 그 “없다”는 결론을 수분에서 수시간 동안 유지할 수 있다. SOA의 negative TTL이 300~3600초라면 몇 분에서 한 시간 단위의 잔상이 생기고, 86400초처럼 길게 잡혀 있으면 하루 동안 “없는 이름”으로 남을 수 있다.

상황:
10:00  api.example.com 레코드를 삭제한 상태로 2분간 배포됨
10:01  public resolver A가 api.example.com을 질의하고 NXDOMAIN을 캐시
10:02  레코드를 복구함
10:03  authoritative는 정상 IP를 응답
10:30  resolver A 뒤의 사용자는 여전히 NXDOMAIN을 받을 수 있음

이것이 negative caching silent failure다. 원본은 복구됐고 모니터링도 authoritative 직접 조회만 보면 정상인데, 일부 사용자는 계속 “도메인이 없다”는 응답을 받는다. 복구 확인도 두 갈래로 나눠야 한다. authoritative 서버를 직접 조회해 정답이 돌아오는지 확인하고, public resolver가 여전히 NXDOMAIN을 주는지 확인한다. 둘의 결과가 다르면 원본 복구 문제가 아니라 negative cache 전파 시간 문제일 가능성이 높다.

출처: RFC 2308 §5 — Caching Negative Answers, RFC 9520 — Negative Caching of DNS Resolution Failures

5-5. 캐시는 한 곳에만 있지 않다

DNS TTL은 authoritative가 resolver에게 주는 숫자지만, 사용자가 체감하는 이름 해석에는 여러 캐시가 겹친다.

계층	무엇을 캐시하는가	흔한 오해
브라우저	최근 해석한 이름과 연결 후보	브라우저를 새로고침하면 DNS도 항상 새로 본다고 착각한다.
OS stub resolver	프로세스들이 공유하는 DNS 응답	앱을 재시작해도 OS 캐시가 남을 수 있다.
Recursive resolver	많은 사용자에게 줄 응답	authoritative를 고쳐도 이 계층의 TTL이 남으면 사용자 응답은 그대로다.
애플리케이션/SDK	자체 DNS cache 또는 connection pool	DNS가 바뀌어도 이미 열린 TCP 연결은 계속 이전 대상과 통신할 수 있다.

마지막 행이 중요하다. DNS는 새 연결을 어디로 보낼지 정하지만, 이미 맺어진 TCP 연결을 강제로 이동시키지 않는다. ALB 교체 후에도 일부 클라이언트가 이전 연결을 계속 쓰는 현상은 DNS TTL만으로 설명되지 않을 수 있다. 이 경우에는 HTTP keep-alive, connection pool lifetime, client retry 정책까지 함께 봐야 한다.

5-6. TTL 손계산 — 비용과 전파 시간의 교환

하나의 public resolver 뒤에서 api.example.com 조회가 초당 1,000번 발생한다고 가정하자. TTL이 300초라면 이론적으로 그 resolver는 5분에 한 번 authoritative에 다시 물으면 된다. 5분 동안 사용자 질의는 300,000번이지만 authoritative 질의는 1번에 가까워진다.

TTL을 30초로 낮추면 같은 5분 동안 authoritative 질의는 약 10번으로 늘어난다. 단일 resolver 기준으로는 작아 보이지만, 전 세계 수천 개 resolver에서 동시에 발생하면 authoritative query 비용과 지연 민감도가 올라간다.

TTL 300초:
5분 동안 resolver당 authoritative 재질의 ≈ 1회

TTL 30초:
5분 동안 resolver당 authoritative 재질의 ≈ 10회

차이:
변경 반영 가능 시간은 10배 빨라지지만,
authoritative 조회 기회도 10배 많아진다.

이 손계산은 정확한 과금 모델을 만들기 위한 것이 아니라 TTL 선택의 방향을 잡기 위한 것이다. “전환 실패 비용이 큰가, 조회 부하와 비용이 큰가”를 먼저 정하면 TTL 값은 그 결과로 나온다.

5-7. 캐싱 반례 — TTL이 짧아도 즉시 전환은 아니다

TTL 60초는 “최대 60초 안에 전 세계가 새 주소를 본다”는 보장이 아니다.

• 일부 resolver는 최소 TTL 정책을 적용해 너무 짧은 TTL을 더 길게 잡을 수 있다.
• 클라이언트 애플리케이션이 자체 DNS cache를 TTL보다 오래 유지할 수 있다.
• 기존 TCP/TLS 연결은 DNS 재조회 없이 계속 재사용될 수 있다.
• 모바일 네트워크나 기업 프록시는 public resolver와 다른 캐시 정책을 가질 수 있다.

그래서 DNS 전환의 성공 기준은 “레코드를 바꿨다”가 아니라 “주요 resolver와 실제 클라이언트 경로에서 새 대상 응답과 연결 성공률이 충분히 올라왔다”다. DNS는 전파 시간을 줄이는 도구이지, 모든 클라이언트 상태를 즉시 동기화하는 제어 plane은 아니다.

---

6. 레코드 타입 — 어떤 질문에 어떤 답을 줄 것인가

레코드	용도	예시	주의점
A	이름을 IPv4로 연결	api.example.com -> 52.94.1.2	ALB처럼 IP가 바뀌는 대상에는 직접 고정 IP를 쓰지 않는다.
AAAA	이름을 IPv6로 연결	api.example.com -> 2001:db8::1	IPv6 경로와 방화벽도 같이 준비되어야 한다.
CNAME	이름을 다른 이름으로 연결	www.example.com -> example.com	다른 레코드와 공존할 수 없고 zone apex에는 둘 수 없다.
MX	메일 수신 서버 지정	10 mail.example.com	우선순위 숫자가 낮을수록 먼저 시도한다.
TXT	텍스트 검증 데이터	SPF, DKIM, 도메인 소유 확인	따옴표·분할 문자열 처리 때문에 복사 오류가 잦다.
NS	zone의 authoritative nameserver 지정	example.com NS ns-123.awsdns-45.com	등록사와 hosted zone의 NS 불일치가 흔한 장애 원인이다.
SOA	zone 권한·시리얼·negative TTL 정보	SOA ns-123... hostmaster...	negative caching 판단에서 중요하다.

6-1. CNAME과 Alias의 경계

CNAME은 “이 이름의 정답은 다른 이름을 따라가라”는 표준 레코드다.

www.example.com.  CNAME  example.com.

그러나 zone apex, 즉 example.com 자체에는 CNAME을 둘 수 없다. Apex에는 NS와 SOA가 반드시 있어야 하는데, CNAME은 같은 이름의 다른 레코드와 공존할 수 없기 때문이다.

불가능:
example.com.  CNAME  alb-1234.ap-northeast-2.elb.amazonaws.com.

이유:
example.com.  NS   ...
example.com.  SOA  ...
example.com.  CNAME ...

Route 53의 Alias Record는 이 문제를 AWS 리소스에 대해 우회하는 기능이다.

가능:
example.com.  A  ALIAS  d111111abcdef8.cloudfront.net.
api.example.com. A ALIAS  alb-api-1234.ap-northeast-2.elb.amazonaws.com.

비교	CNAME	Route 53 Alias
DNS 표준	표준	AWS 확장
Zone apex 사용	불가	가능
대상	임의의 도메인 이름	CloudFront, ALB/NLB, S3 website, API Gateway 등 AWS 대상
응답 모양	CNAME 체인을 따라간다	최종 A/AAAA처럼 응답한다
TTL	직접 설정	대상 AWS 리소스 정책을 따르는 경우가 많다
비용	일반 DNS query 과금	AWS Alias 대상에 따라 유리한 과금이 적용될 수 있다

결정 기준은 단순하다. www.example.com처럼 하위 이름을 다른 이름에 붙이면 CNAME이 자연스럽다. example.com 자체를 ALB나 CloudFront에 붙이면 Alias가 필요하다.

관찰할 때도 차이가 난다. CNAME은 응답에 “다른 이름을 따라가라”는 중간 이름이 보이지만, Route 53 Alias는 사용자가 질의한 이름에 대해 최종 A/AAAA 응답처럼 보인다. 그래서 example.com을 ALB Alias로 연결했는데 dig example.com에서 CNAME이 안 보이는 것은 이상이 아니라 Alias의 의도된 동작이다.

6-2. TXT 레코드는 “소유권과 정책”을 싣는다

TXT는 IP 라우팅보다 인증과 정책에 자주 등장한다.

example.com.               TXT "v=spf1 include:amazonses.com ~all"
selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=..."
_github-challenge.example.com.   TXT "..."

TXT 장애는 서비스 연결 실패보다 “외부 서비스가 도메인 소유를 인정하지 않음”, “메일이 스팸 처리됨”, “OIDC/인증 설정이 통과하지 않음”으로 나타난다. DNS 문서에서 TXT를 기억해야 하는 이유는 레코드 타입이 다르지만 장애의 본질이 여전히 권한 있는 zone에 올바른 데이터를 넣었는가이기 때문이다.

6-3. CNAME chain worked example

CNAME은 이름을 한 번 더 따라가게 한다. 한 단계 정도는 자연스럽지만, 체인이 길어질수록 지연과 실패 지점이 늘어난다.

shop.example.com.     CNAME  shops.platform.example.net.
shops.platform.example.net. CNAME  edge.vendor.example.org.
edge.vendor.example.org.    A      203.0.113.20

resolver는 최종 A/AAAA를 얻기 위해 chain을 따라간다. 각 이름에는 별도 TTL이 붙을 수 있다.

이름	TTL	의미
shop.example.com CNAME shops.platform...	300초	우리 zone에서 vendor 이름으로 넘긴다.
shops.platform... CNAME edge.vendor...	60초	vendor가 edge 이름을 바꿀 수 있다.
edge.vendor... A 203.0.113.20	20초	실제 edge IP는 자주 바뀔 수 있다.

이 chain의 실제 전환 속도는 가장 짧은 TTL 하나로만 결정되지 않는다. 중간 CNAME이 길게 캐시되면 vendor가 최종 A를 바꿔도 사용자는 여전히 같은 중간 이름을 따라간다. 반대로 최종 A TTL만 짧으면 IP 교체는 빠르지만, 우리 zone에서 vendor를 바꾸는 전환은 첫 CNAME TTL에 묶인다.

6-4. CNAME을 피해야 하는 반례

첫 번째 반례는 zone apex다. example.com에는 NS와 SOA가 필요하므로 CNAME을 둘 수 없다. 이 경우 Route 53 Alias나 직접 A/AAAA가 필요하다.

두 번째 반례는 내부 서비스 이름이다. db.internal.example.com CNAME public-rds.example.com처럼 내부 이름이 public 이름을 따라가면, VPC 내부에서만 닫혀 있어야 할 의존성이 public DNS와 public 네트워크 정책에 묶일 수 있다. 내부 의존성은 Private Hosted Zone에서 내부 대상 이름이나 private endpoint를 가리키게 두는 편이 안전하다.

세 번째 반례는 메일과 인증 레코드다. 많은 서비스는 MX, TXT, CAA처럼 특정 이름에 특정 타입의 레코드가 직접 있기를 기대한다. 이 이름을 CNAME으로 돌리면 검증기가 CNAME을 따라가지 않거나 정책상 거부할 수 있다. 도메인 소유 확인이 실패할 때는 “값이 맞나”뿐 아니라 “그 이름이 CNAME이 아닌가”도 확인한다.

6-5. Alias를 과신하면 안 되는 지점

Alias는 Route 53에서 AWS 리소스를 편하게 가리키는 기능이지만, DNS 표준 CNAME을 대체하는 일반 메커니즘은 아니다.

• AWS 밖의 임의 SaaS 도메인을 apex에 붙일 때는 Alias 대상이 아닐 수 있다.
• Alias가 ALB 상태를 자동으로 완벽히 판단해 주는 것은 아니다. Health Check와 evaluate_target_health의 의미를 따로 봐야 한다.
• Alias 응답은 사용자가 볼 때 A/AAAA처럼 보이므로, “CNAME이 안 보인다”는 이유만으로 설정이 빠진 것은 아니다.

결정 기준은 “어떤 레코드가 더 멋진가”가 아니라 표준 제약, 대상 리소스의 성격, 운영자가 전환을 제어해야 하는 지점이다.

---

7. Route 53과 트래픽 라우팅 — DNS는 로드밸런서가 아니다

Route 53은 DNS 응답을 바꿔 트래픽 방향을 유도한다. 하지만 이미 DNS 응답을 캐시한 클라이언트의 연결을 즉시 끊거나, HTTP 요청 단위로 정교하게 분산하지는 못한다. 이 차이를 알아야 Failover와 Latency routing을 과신하지 않는다.

7-1. api.example.com -> ALB 구성

가장 흔한 API 구성은 Hosted Zone 안에 Alias 레코드를 두는 것이다.

example.com Hosted Zone
└── api.example.com
    └── A/AAAA Alias -> alb-api-1234.ap-northeast-2.elb.amazonaws.com

애플리케이션 코드 입장에서는 https://api.example.com만 호출한다. DNS는 이름을 ALB 주소로 바꾸고, 실제 HTTP 라우팅과 타깃 상태 관리는 ALB가 처리한다. 프론트엔드든 서버든 별도 서브도메인을 호출하면 DNS 조회와 TLS 연결 비용이 생길 수 있지만, 그 비용보다 도메인·캐시·라우팅 정책을 독립 관리하는 이점이 더 클 때 분리한다.

7-2. Route 53 라우팅 정책 선택 기준

상황	정책	왜 쓰는가	실패 신호
단일 ALB나 CloudFront로 연결	Simple	가장 적은 운영 복잡도	장애 시 대체 경로가 없다.
카나리 또는 점진 배포	Weighted	90:10, 50:50처럼 비율을 조정한다	TTL 때문에 사용자가 즉시 비율대로 움직이지 않는다.
여러 리전 중 가까운 곳 선택	Latency	AWS가 측정한 지연 기준으로 응답한다	실제 앱 지연이 아니라 DNS 관점의 리전 선택임을 혼동한다.
Primary 장애 시 Secondary로 전환	Failover	Health Check 상태에 따라 응답을 바꾼다	Health Check가 잘못되면 정상 Primary도 제외된다.
국가·지역별 다른 응답	Geolocation	규정, 언어, 콘텐츠 차이를 반영한다	Default 레코드가 없으면 매칭되지 않는 지역이 응답을 못 받는다.

7-3. Active-Passive와 Active-Active

Active-Passive는 평소 Primary만 응답하고, Health Check 실패 시 Secondary를 응답한다. 비용은 낮지만 전환 시간은 Health Check 주기, 실패 판정 횟수, TTL, 클라이언트 캐시에 영향을 받는다.

정상:
api.example.com -> Primary ALB

Primary 장애:
Health Check 실패 -> Route 53이 Secondary ALB 응답

Active-Active는 여러 리전이 동시에 트래픽을 처리한다. Weighted나 Latency 정책과 Health Check를 함께 사용해 장애 리전을 응답에서 제외한다. 비용과 데이터 정합성 설계는 더 어렵지만, 한 리전 장애가 전체 중단으로 번질 가능성은 낮다.

선택 기준은 “DNS 설정을 얼마나 빨리 바꿀 수 있는가”가 아니라 데이터와 애플리케이션이 여러 리전에서 동시에 처리될 준비가 되었는가다. DNS만 Active-Active로 바꿔도 DB 쓰기 충돌, 세션 저장소, 캐시 일관성이 준비되지 않으면 장애 형태만 바뀐다.

7-4. Health Check는 트래픽 판단의 입력일 뿐이다

Route 53 Health Check가 unhealthy라고 해서 서버가 반드시 죽은 것은 아니다. 다음 경우에도 unhealthy가 될 수 있다.

• /health 경로가 200이 아닌 301, 403, 500을 반환한다.
• Health Checker IP 대역이 Security Group에서 막혀 있다.
• HTTPS Health Check에서 SNI(Server Name Indication)가 맞지 않아 TLS handshake가 실패한다.
• ALB는 정상인데 애플리케이션 health endpoint가 DB 의존성 때문에 실패한다.

따라서 Failover 장애를 볼 때는 “DNS가 틀렸다”보다 먼저 “Health Check가 무엇을 관측했고, 그 관측이 실제 사용자 경로를 대표하는가”를 확인한다.

7-5. Weighted routing worked example

신버전 API를 10%만 노출하려고 api.example.com에 두 레코드를 둔다고 하자.

api.example.com  A/ALIAS  old-alb  weight 90  TTL 60
api.example.com  A/ALIAS  new-alb  weight 10  TTL 60

이 설정은 “모든 HTTP 요청 100개 중 정확히 10개가 new-alb로 간다”는 뜻이 아니다. DNS resolver가 질의할 때마다 가중치에 따라 응답이 선택되고, 그 응답은 TTL 동안 캐시된다. 한 회사 네트워크의 많은 사용자가 같은 resolver를 쓰면, 그 resolver가 new-alb를 받은 60초 동안 그 뒤의 사용자 다수가 new-alb로 갈 수 있다.

Weighted routing은 카나리의 시작점으로 좋지만, 요청 단위 정밀 제어가 필요하면 애플리케이션 로드밸런서, feature flag, edge worker 같은 더 안쪽 계층이 필요하다. DNS는 사용자를 “대략 어느 대상군으로 보낼지” 정하는 데 강하고, 개별 요청을 세밀하게 제어하는 데는 약하다.

7-6. Latency와 Geolocation은 다른 질문에 답한다

Latency routing과 Geolocation routing은 둘 다 “지역별 응답”처럼 보이지만 질문이 다르다.

정책	답하는 질문	예시
Latency	이 사용자에게 지연이 낮을 가능성이 큰 AWS 리전은 어디인가?	한국 사용자를 서울 리전, 미국 동부 사용자를 버지니아 리전으로 보냄
Geolocation	이 사용자의 국가/지역 정책상 어떤 대상을 줘야 하는가?	EU 사용자는 EU 리전, 특정 국가는 별도 콘텐츠

반례를 보자. 한국 사용자가 일본 출장 중 회사 VPN으로 미국 egress를 사용하면, DNS는 사용자의 물리적 위치가 아니라 resolver와 네트워크 관측 정보를 기준으로 판단할 수 있다. Latency routing이 “사용자의 GPS 위치”를 보는 것은 아니다.

Geolocation은 정책 기반이라 더 명시적이지만 default가 없으면 위험하다. 어떤 국가 코드에도 매칭되지 않는 사용자가 있을 수 있고, 이때 default 레코드가 없으면 정상 서비스가 특정 지역에서만 NXDOMAIN처럼 보일 수 있다.

7-7. Failover 시간은 TTL만으로 정해지지 않는다

Active-Passive failover에서 전환 시간은 여러 항목의 합성 결과다.

감지 시간:
Health Check 주기 x 실패 판정 횟수

DNS 응답 변경:
Route 53이 Primary를 응답에서 제외

사용자 전환:
기존 resolver cache TTL 만료
+ 클라이언트 재시도
+ 기존 연결 종료

예를 들어 Health Check가 30초 간격으로 3번 실패해야 unhealthy가 되고, TTL이 60초라면 단순 계산으로도 감지에 최대 90초, 캐시 만료에 최대 60초가 더해질 수 있다. 실제 사용자는 여기에 HTTP retry, connection pool, 모바일 네트워크 캐시 영향을 더 받는다.

이 때문에 RTO(Recovery Time Objective)가 초 단위라면 DNS Failover만으로 충분하지 않을 수 있다. Global Accelerator, ALB/NLB 레벨의 health routing, 애플리케이션 retry와 idempotency, 데이터 복제 전략까지 같이 설계해야 한다. DNS Failover는 재해 복구의 한 요소이지 전체 고가용성 설계가 아니다.

7-8. Route 53 정책 선택의 실패 비용

정책을 고를 때는 기능 이름보다 실패 비용을 먼저 본다.

실패 비용	더 맞는 방향	이유
잘못된 버전이 일부 사용자에게만 가도 위험	Weighted보다 앱 내부 feature flag	DNS cache 때문에 즉시 회수하기 어렵다.
리전 장애 시 읽기만 유지해도 됨	Active-Passive + 명확한 health check	쓰기 정합성 부담을 줄일 수 있다.
모든 리전에서 쓰기가 필요	Active-Active 이전에 데이터 설계	DNS보다 DB 충돌과 세션 일관성이 더 큰 문제다.
특정 국가 법규가 중요	Geolocation + default	성능보다 정책 매칭이 우선이다.
SaaS vendor 전환 가능성이 중요	낮은 TTL + CNAME 경계 명확화	vendor lock-in과 전환 시간을 관리한다.

이 표는 “어떤 Route 53 버튼을 누를지”가 아니라 DNS가 해결할 수 있는 문제와 해결하지 못하는 문제를 나누는 기준이다.

---

8. DNSSEC과 SERVFAIL — 응답이 있어도 버릴 수 있다

DNSSEC(DNS Security Extensions)은 DNS 응답의 출처와 무결성을 검증하기 위한 확장이다. 목적은 암호화가 아니라 **“이 응답이 위임 체인상 권한 있는 zone에서 서명된 데이터인가”**를 검증하는 것이다.

8-1. DNSSEC이 보장하는 것과 보장하지 않는 것

구분	DNSSEC의 역할
보장	응답 데이터가 위임된 zone의 키로 서명되었는지 검증한다.
보장	NXDOMAIN도 서명된 부재 증명으로 검증할 수 있다.
보장하지 않음	질의 내용을 숨기지 않는다. 프라이버시는 DoH/DoT의 관심사다.
보장하지 않음	서버가 정상 동작하는지 보장하지 않는다. DNSSEC은 health check가 아니다.

8-2. 왜 SERVFAIL로 보이는가

DNSSEC 검증 resolver는 서명 체인이 깨진 응답을 사용자에게 그대로 주지 않는다. 상위 zone의 DS 레코드와 하위 zone의 DNSKEY가 맞지 않거나, RRSIG 서명이 만료되거나, zone 재서명이 잘못되면 resolver는 검증 실패로 보고 SERVFAIL을 반환할 수 있다. 처음에는 세 지점만 구분해도 충분하다. 부모 zone이 위임한 DS, 자식 zone이 가진 DNSKEY, 실제 응답에 붙은 RRSIG 중 하나가 어긋나면 데이터는 존재해도 검증 가능한 응답이 아니게 된다.

체인 지점	깨졌을 때의 의미
DS	부모 zone이 “이 자식 zone 키를 믿어라”라고 가리키는 정보가 틀렸거나 오래됐다.
DNSKEY	자식 zone이 제시하는 공개 키가 부모의 DS와 이어지지 않는다.
RRSIG	실제 응답 데이터의 서명이 만료됐거나 현재 키로 검증되지 않는다.

Authoritative:
api.example.com A 52.94.1.2 + RRSIG

검증 resolver:
DS/DNSKEY/RRSIG 체인 확인
-> 체인이 깨짐
-> 사용자에게 SERVFAIL 반환

중요한 반례는 +cd(Checking Disabled)로 검증을 끄면 응답이 보일 수 있다는 점이다. 이것은 “DNS가 정상”이라는 뜻이 아니라 권한 서버에는 데이터가 있지만 검증 가능한 데이터가 아니다라는 신호다.

출처: RFC 4035 §5.3 — Authenticating DNS Responses

---

9. 실패 신호로 읽는 DNS

DNS 장애는 긴 명령어보다 증상과 원리를 먼저 잡는 편이 빠르다. 아래 표는 본문 개념을 실제 현상으로 연결하는 지도다.

증상	의미	먼저 의심할 개념	첫 확인
일부 사용자만 이전 IP로 접속	resolver별 positive cache가 남아 있음	TTL, migration timing	public resolver별 응답 차이
authoritative는 정상인데 public resolver는 NXDOMAIN	부정 응답이 캐시됨	Negative TTL, SOA MINIMUM	authoritative 직접 조회와 public resolver 조회 비교
SERVFAIL만 보임	resolver가 응답을 검증하거나 처리하지 못함	DNSSEC, 위임 체인, TCP fallback	검증 끈 조회와 DNSSEC 체인 확인
VPC 안에서는 되는데 노트북에서는 안 됨	private zone 또는 split-horizon	resolver 위치, Private Hosted Zone	질의 위치와 resolver IP 기록
노트북에서는 되는데 ECS task 안에서는 안 됨	VPC DNS, DHCP option, private hosted zone 연결 문제	VPC resolver, zone association	VPC와 hosted zone association
특정 국가만 NXDOMAIN	Geolocation default 누락	Route 53 routing policy	default record 존재 여부
Failover가 항상 Secondary로 감	Primary health check가 실패	Health Check, SG, SNI	health check 관측 경로
긴 CNAME 체인 또는 순환	이름이 최종 A/AAAA에 도달하지 못함	CNAME 경계	chain 길이와 순환 여부
작은 레코드는 되는데 DNSSEC/TXT만 실패	큰 응답의 UDP truncation 후 TCP fallback 실패	UDP/TCP 53, EDNS, 방화벽	TCP 53 허용 여부
메일 인증만 실패	TXT/MX 레코드가 authoritative zone에 없거나 값이 다름	TXT, MX, zone authority	권한 zone의 TXT/MX 값

9-1. NXDOMAIN silent failure worked example

가장 위험한 DNS 장애는 “원본은 고쳤는데 사용자 쪽 실패가 오래 남는” 형태다.

1. 10:00 배포 실수로 api.example.com 레코드가 잠시 삭제됨
2. 10:01 Google Public DNS가 NXDOMAIN을 받음
3. 10:02 운영자가 레코드를 복구함
4. 10:03 Route 53 authoritative 직접 조회는 정상 IP를 반환함
5. 10:30 일부 사용자는 여전히 NXDOMAIN을 받음

이때 문제의 핵심은 레코드 복구가 아니라 부정 응답 캐시의 잔여 시간이다. 이미 캐시된 NXDOMAIN은 authoritative를 고쳐도 즉시 사라지지 않는다. 해결은 public resolver purge 요청, 사용자/OS 캐시 우회 안내, SOA negative TTL 재점검처럼 “캐시된 부정 응답을 어떻게 줄일 것인가”로 잡아야 한다.

9-2. dig +trace는 경로를 읽는 도구다

dig +trace api.example.com의 목적은 모든 문제를 자동 진단하는 것이 아니라 위임 경로를 눈으로 보는 것이다.

.                  NS  a.root-servers.net.
com.               NS  a.gtld-servers.net.
example.com.       NS  ns-123.awsdns-45.com.
api.example.com.   A   52.94.1.2

이 출력은 네 줄의 의미만 읽어도 충분하다.

1. Root가 TLD 담당자를 알려줬는가?
2. TLD가 example.com의 authoritative NS를 알려줬는가?
3. 그 NS가 실제로 내가 기대한 Route 53 Hosted Zone의 NS인가?
4. 마지막 authoritative 응답이 기대한 A/AAAA/CNAME/Alias 결과인가?

+trace는 recursive resolver 캐시를 우회해 위임 경로를 직접 따라가므로, “권한 경로 자체가 맞는지” 확인할 때 좋다. 반대로 사용자 장애가 resolver 캐시 문제라면 +trace만 정상이어도 사용자는 계속 실패할 수 있다.

---

10. 새 이름 해결 시스템을 만났을 때 보는 질문

DNS에서 배운 패턴은 CDN, HTTP cache, Redis, Kubernetes Service Discovery, Consul에서도 반복된다. 다음 문서인 HTTP Cache를 읽을 때도 TTL과 stale 응답의 trade-off는 거의 같은 형태로 나타난다.

질문	DNS에서의 답	다른 시스템에서 확인할 것
권한 있는 원본은 누구인가?	Authoritative nameserver	DB 원본, origin server, Kubernetes API server
캐시는 몇 단계인가?	브라우저, OS, recursive resolver	CDN edge, browser cache, local cache, Redis
유효 시간은 어디서 정하는가?	Record TTL, SOA negative TTL	Cache-Control, Redis EXPIRE, service discovery TTL
”없다”는 응답도 캐시되는가?	NXDOMAIN/NODATA negative caching	404 cache, empty result cache, circuit breaker open 상태
stale 응답을 허용하는가?	일부 resolver의 serve-stale	CDN stale-while-revalidate, Redis fallback
권한과 무결성은 누가 보장하는가?	NS delegation, DNSSEC	mTLS, IAM, RBAC, signed metadata

이 질문의 목적은 새 시스템을 DNS로 억지 비유하는 것이 아니라, 위임·캐싱·전파 지연·권한 검증이라는 반복되는 문제를 빠르게 찾는 것이다.

---

11. 선택 기준 모음

11-1. TTL 선택

조건	권장 출발점	이유
일반 API 레코드	300초	전환 가능성과 캐시 효율의 균형
마이그레이션 직전	60초	이전 TTL 만료를 기다린 뒤 빠르게 전환
거의 변하지 않는 내부 이름	300~3600초	내부 resolver 부하와 운영 안정성 균형
위임 정보(NS)	길게	자주 바뀌지 않고 안정성이 중요
실험·카나리	30~60초	비율 조정 관찰이 중요하지만 비용 증가를 감수

11-2. CNAME, Alias, A 레코드 선택

목표	선택	피해야 할 것
www.example.com을 다른 이름에 붙임	CNAME	CNAME 체인을 너무 길게 만들기
example.com을 CloudFront/ALB에 붙임	Route 53 Alias	Zone apex에 CNAME 두기
고정 IP 하나로 직접 연결	A/AAAA	ALB처럼 IP가 바뀌는 대상을 직접 A로 고정
내부 DB 엔드포인트 별칭	CNAME 또는 Private Hosted Zone 레코드	public zone에 내부 이름 노출

11-3. Public DNS와 Private DNS 선택

조건	선택
인터넷 사용자가 접근해야 함	Public Hosted Zone
VPC 내부 서비스끼리만 접근	Private Hosted Zone
같은 이름을 내부와 외부에서 다르게 해석	Split-horizon, 단 디버깅 비용을 감수
보안 경계가 필요	DNS가 아니라 네트워크·인증 정책으로 구현

11-4. Route 53 라우팅 정책 선택

요구	선택	경계
가장 단순한 운영	Simple	장애 자동 전환 없음
새 버전 일부 노출	Weighted	TTL 때문에 즉시 정확한 비율은 아님
사용자 가까운 리전 선택	Latency	실제 애플리케이션 부하를 직접 보지는 않음
DR 전환	Failover	Health Check 설계가 품질을 좌우
국가별 정책	Geolocation	Default 레코드 누락 주의

---

12. 선택 부록 — 최소 명령 해석

본문은 명령어 없이도 이해할 수 있어야 한다. 다만 실제 장애에서는 아래 세 가지 확인이 가장 자주 필요하다.

권한 경로 확인: dig +trace

dig +trace api.example.com

읽을 지점:

• Root가 TLD NS를 반환하는가?
• TLD가 기대한 authoritative NS를 반환하는가?
• 마지막 authoritative 응답이 기대한 레코드인가?
• 중간에 SERVFAIL, timeout, 엉뚱한 NS가 보이는가?

authoritative와 public resolver 비교

dig @ns-123.awsdns-45.com api.example.com
dig @8.8.8.8 api.example.com
dig @1.1.1.1 api.example.com

해석:

• authoritative는 정상인데 public resolver만 이전 값이면 TTL 캐시 문제일 가능성이 높다.
• authoritative는 정상인데 public resolver만 NXDOMAIN이면 negative caching을 의심한다.
• authoritative부터 틀리면 Hosted Zone 레코드, delegation, 배포 상태를 먼저 본다.

SOA와 negative TTL 확인

dig SOA example.com +short

SOA에는 primary NS, 담당자, serial, refresh, retry, expire, minimum 계열 값이 들어 있다. NXDOMAIN이 오래 남는 장애에서는 SOA의 TTL과 negative caching 관련 값이 얼마나 긴지 확인한다.

DNSSEC 의심 시 최소 분리

dig api.example.com
dig api.example.com +cd
dig api.example.com +dnssec

해석:

• 일반 조회는 SERVFAIL인데 +cd에서 응답이 보이면 DNSSEC 검증 실패 가능성이 크다.
• +dnssec 응답에서 RRSIG, DNSKEY, DS 체인을 확인한다.
• 이 경우 레코드 값보다 서명 만료, DS-DNSKEY 불일치, KSK 상태를 먼저 본다.

---

13. 체크리스트

DNS 설정 완료 기준

• 도메인 등록사의 NS가 실제 Hosted Zone NS와 일치한다.
• Public Hosted Zone과 Private Hosted Zone의 해석 범위를 구분했다.
• Zone apex에는 CNAME 대신 Alias 또는 A/AAAA를 사용했다.
• ALB, CloudFront 같은 AWS 관리 대상에는 직접 고정 IP를 쓰지 않았다.
• TTL 값을 변경 빈도와 장애 전환 목표에 맞게 정했다.
• 마이그레이션 전 기존 TTL이 만료될 시간을 계획에 포함했다.
• SOA와 negative TTL이 NXDOMAIN 복구 시간을 과도하게 늘리지 않는지 확인했다.
• Route 53 Failover는 Health Check 경로, Security Group, SNI 조건까지 검증했다.
• Geolocation 정책에는 매칭되지 않는 사용자를 위한 Default 레코드가 있다.
• DNSSEC을 켰다면 DS, DNSKEY, RRSIG 갱신 절차와 알림을 준비했다.
• 장애 확인 시 authoritative 응답과 public resolver 응답을 분리해서 비교했다.
• 큰 응답이나 DNSSEC 사용 시 TCP 53 fallback이 막히지 않는지 확인했다.

---

14. 추가 학습 키워드

Route 53 Health Check, Private Hosted Zone, Split-horizon DNS, DNSSEC, GeoDNS, DNS over HTTPS(DoH), DNS over TLS(DoT), Anycast DNS, EDNS(Extension Mechanisms for DNS), Serve Stale, CoreDNS, Consul DNS

15. 출처 / 추천 리소스

• RFC 1034 — Domain names: concepts and facilities
• RFC 1035 — Domain names: implementation and specification
• RFC 2308 — Negative Caching of DNS Queries
• RFC 4035 — Protocol Modifications for DNSSEC
• AWS Route 53 Developer Guide — Routing policy
• Cloudflare Learning Center — What is DNS?

---

16. 요약

DNS는 도메인을 IP로 바꾸는 기능을 넘어, 이름 공간을 계층적으로 위임하고 그 결과를 TTL 동안 캐시하는 분산 시스템이다. Recursive resolver는 Root → TLD → Authoritative 경로를 따라가며 정답을 찾고, 클라이언트는 그 최종 답만 받는다.

학습의 중심은 세 가지다.

1. 위임: 누가 이 이름의 정답을 말할 권한이 있는가?
2. 캐싱: 그 정답 또는 “없다”는 응답이 어디에 얼마나 오래 남는가?
3. 판단: TTL, CNAME/Alias, public/private zone, Route 53 라우팅 정책을 어떤 실패 비용 기준으로 고를 것인가?

DNS 장애는 대부분 이 세 질문 중 하나로 돌아온다. NS가 틀리면 권한 경로가 깨진 것이고, TTL이 길면 오래된 답이 남은 것이며, DNSSEC SERVFAIL은 응답 값보다 검증 체인이 깨진 것이다. 명령어는 이 원리를 확인하는 도구일 뿐이고, 먼저 잡아야 할 것은 위임·캐시·권한의 경계다.