[Network] DNS 조회는 어떤 단계로 이루어질까?(feat.. GSLB, 재귀/반복 질의, 캐시, TTL)

0. 상황

GSLB(Global Server Load Balancing)를 공부하다가 "GSLB는 DNS의 권한 네임서버(authoritative name server) 자리에 끼어들어 적합한 지역의 IP를 동적으로 응답한다"는 설명을 만났다. "권한 네임서버"가 DNS 조회 과정의 정확히 어느 지점인지 헷갈려 이참에 DNS 조회 전체 단계를  GSLB 를 포함해 정리해두기로 했다.

1. DNS가 풀려는 문제

사람은 www.example.com 같은 이름을 쓰지만, 실제 통신은 93.184.216.34 같은 IP로 이루어진다. 이 이름 → IP 변환이 DNS(Domain Name System)의 역할이다.

핵심은 이 정보가 한 군데가 아니라 전 세계에 계층적으로 분산되어 있다는 점이다. 그래서 한 번에 끝나지 않고 여러 서버를 거친다.

2. 등장인물 정리

조회 과정에 나오는 서버들을 먼저 정리하고 가자. 역할이 꽤 명확하게 나뉘어 있다.

Stub Resolver
내 PC나 브라우저 안에 있는 작은 DNS 요청기다. 직접 조회를 돌아다니지는 않고, "이 이름의 IP 좀 찾아줘"라고 Local DNS에게 통째로 맡기기만 한다. 운영체제의 DNS 설정에 잡힌 서버(보통 Local DNS)로 질의를 던지는 게 이 친구의 일이다.

Local DNS (재귀 resolver)
보통 통신사(ISP)가 운영하거나, 8.8.8.8(구글)·1.1.1.1(클라우드플레어) 같은 공용 DNS다. 이름 그대로 "재귀적으로" 끝까지 조회를 책임지는 핵심 일꾼으로, Root → TLD → 권한 NS를 직접 돌아다니며 답을 알아온다. 한 번 알아낸 답은 캐시에 저장해뒀다가 다음 요청에 재사용하기 때문에, 실제 트래픽의 상당수가 이 캐시 선에서 처리된다.

Root DNS
계층의 최상위에 있는 서버다. 개별 도메인의 IP를 직접 알지는 못하고, ".com은 어느 TLD 서버가 관리한다" 같은 최상위 분기 정보만 안다. 전 세계에 13개의 루트 서버 그룹이 분산 운영된다는 점도 특징이다.

TLD DNS (Top-Level Domain)
.com, .net, .kr, .org 같은 최상위 도메인을 담당한다. 여기도 개별 호스트의 IP를 아는 게 아니라, "example.com은 어느 권한 네임서버가 관리한다"는 위임 정보를 안다. Root가 ".com은 저쪽" 하고 넘기면, 그 .com을 받아주는 게 이 단계다.

Authoritative Name Server (권한 네임서버)
해당 도메인의 최종 답을 직접 가진 서버다. "www.example.com의 IP는 93.184.216.34"라고 확정적으로(authoritative) 응답한다. 도메인 소유자가 직접 운영하거나, 외부 DNS 서비스에 위탁해 관리하는 레코드가 실제로 들어있는 곳이다. 그리고 GSLB가 끼어드는 자리가 바로 여기다 — 고정된 답 대신 동적으로 IP를 골라주는 권한 네임서버라고 보면 된다.

3. 전체 조회 흐름

www.example.com을 처음 조회한다고 하자.(캐시가 아무 데도 없는 상태)

브라우저(stub)
  → ① Local DNS 에게:  "www.example.com IP 뭐야?"
        Local DNS 가 캐시 확인 → 없음 → 직접 찾아 나선다
        → ② Root DNS:  "com 은 누가 관리?"   → "TLD(.com) 서버로 가봐"
        → ③ TLD DNS:   "example.com 은?"    → "권한 네임서버로 가봐"
        → ④ 권한 NS:   "www.example.com?"   → "93.184.216.34 야"
  ← Local DNS 가 결과를 받아 브라우저에 전달 (+ 캐시에 저장)
브라우저: 그 IP로 실제 접속 시작

여기서 두 종류의 질의 방식이 섞여 있다.

• 재귀 질의(recursive): 브라우저 → Local DNS 구간. "끝까지 찾아서 답만 줘"라고 통째로 위임한다.
• 반복 질의(iterative): Local DNS → Root → TLD → 권한 NS 구간. "다음에 누구한테 물어보라"는 힌트만 받아가며 Local DNS가 한 단계씩 밟는다.

즉 실제 발품은 대부분 Local DNS가 판다. 그리고 권한 NS(④)는 이 흐름의 맨 끝, 최종 답을 내주는 자리다.

4. 캐시 — 매번 ②③④를 다 돌지는 않는다

위 흐름은 캐시가 하나도 없을 때의 최악 경로다. 실제로는 곳곳의 캐시 덕분에 대부분 중간에 끝난다.

캐시는 여러 층에 있다. 브라우저 캐시, OS 캐시, 그리고 가장 중요한 Local DNS 캐시.

같은 ISP를 쓰는 누군가가 방금 www.example.com을 조회했다면 Local DNS 캐시에 답이 남아있고, 내 요청은 ①에서 바로 끝난다.

브라우저 → Local DNS: "www.example.com?"
Local DNS: (캐시에 있네) "93.184.216.34" → 즉시 응답

5. TTL — 캐시의 유효기간

캐시가 영원하면 IP가 바뀌어도 옛 주소로 가버린다. 그래서 각 응답에는 TTL(Time To Live)이라는 유효기간이 붙는다.

• TTL이 길면(예: 1일): 캐시 효율은 좋지만 IP 변경 반영이 느리다.
• TTL이 짧으면(예: 30~60초): 변경이 빨리 반영되지만 조회가 잦아진다.

6. GSLB는 어디에 있나

처음의 의문으로 돌아오면, GSLB는 ④ 권한 네임서버 자리에 앉는다.

일반 권한 NS는 고정된 답을 읽어주지만, GSLB는 질의를 받는 순간 질의를 보낸 Local DNS의 위치와 각 지역 부하·생존 상태를 계산해 그때그때 다른 IP를 응답한다.

④ 권한 NS = GSLB
   Local DNS: "www.example.com?"
   GSLB: (질의 출발지 + 각 지역 상태 계산) → "지금은 서울 IP"

실무에선 보통 도메인 전체가 아니라 특정 호스트만 CNAME으로 GSLB에 위임한다.

www.example.com   CNAME   gslb.example.com
                          ↑ gslb.example.com 의 권한 NS가 GSLB

여기서 5번의 TTL이 한계로 작용한다. GSLB가 응답을 바꿔도, 이미 그 답을 캐시한 Local DNS를 쓰는 사용자들은 TTL이 끝날 때까지 옛 IP로 간다. 그래서 GSLB는 일반 로드밸런서처럼 실시간으로 트래픽을 옮기지 못하고, 분 단위의 거시적 조정에 가깝다. GSLB가 짧은 TTL을 쓰는 것도 이 반영 지연을 줄이기 위해서다.

7. GSLB는 "적합한 지역"을 어떻게 고르나

그럼 GSLB는 무슨 기준으로 지역을 고를까. 핵심은 단일 기준이 아니라, 여러 정책을 순서대로 적용해 후보를 좁혀나간다는 점이다.

큰 틀은 "거르고 → 고른다"이다.

전체 지역 후보
  → 1단계: 살아있는 곳만 남긴다 (전제 조건)
  → 2단계: 그중 적합한 곳을 고른다 (선택 정책)
  → 최종 IP 응답

선택에 쓰이는 기준들은 대략 이렇다.

• 생존 여부(health): 가장 먼저, 무조건 적용된다. health check에 응답 없는 지역은 즉시 후보에서 제외. 아무리 가깝고 한가해도 죽은 지역은 고려 대상이 아니다.
• 지리적 근접성(geo-proximity): 질의가 들어온 위치와 가까운 지역을 선호한다. 가까울수록 지연시간이 짧다는 전제.
• 지연시간 기반(latency): 근접성의 정밀한 버전. 지리적 거리가 아니라 실제 측정한 응답 속도를 본다. 가까워도 네트워크 경로가 나쁘면 느릴 수 있으니.
• 부하 기반(load): 각 지역의 연결 수·CPU·요청량을 비교해 여유 있는 곳을 고른다.
• 가중치(weighted): "서울 70%, 도쿄 30%" 같은 비율을 미리 정해두고 분배.
• 우선순위/액티브-스탠바이(failover): "평소엔 서울, 죽으면 도쿄"처럼 1·2순위를 정해두는 방식. 재해 복구에 초점.

실제 GSLB는 이 기준들을 하나만 쓰지 않고 우선순위를 두고 조합한다. 그래서 기준끼리 충돌할 때 처리 방식이 실제 동작을 결정한다.

가장 중요한 충돌은 "가까운 곳"과 "한가한 곳" 사이다. 전형적인 처리는, 평소엔 근접성을 우선하되 그 지역의 부하가 임계치(예: CPU 90%)를 넘으면 그때 다음으로 가까운 여유 지역으로 우회시키는 것이다. 가까움이 기본값이고, 부하는 그 기본값을 뒤집는 안전장치 역할을 한다.

이 우선순위를 어떻게 잡느냐는 서비스 성격에 따라 다르다. 지연시간이 생명인 서비스는 근접성을 강하게 우선하고, 안정성이 더 중요한 서비스는 부하·생존 기준을 앞세운다. 결국 "적합한 지역"의 정의 자체가 그 서비스가 무엇을 중시하느냐에 달려 있는 셈이다.

8. 정리

• DNS 조회는 계층적이다: Root → TLD → 권한 NS 순으로 좁혀간다.
• 브라우저→Local DNS는 재귀, Local DNS→나머지는 반복 질의다. 발품은 Local DNS가 판다.
• 캐시로 대부분 흐름이 단축되고, 캐시 수명은 TTL이 정한다.
• GSLB는 권한 네임서버 자리에서 고정 답 대신 동적으로 IP를 고른다. 단 캐시/TTL 때문에 반영에 시차가 있다.
• GSLB의 지역 선택은 생존→근접성→부하 순으로 거르고 고르는 정책의 조합이며, 기준이 충돌하면 우선순위로 결정된다.