모범답안 — DNS 동작 원리, 서버 디스커버리, Anycast/지역 라우팅

난이도: 중

핵심 답변

DNS 해석: 클라이언트 → 재귀 리졸버(보통 ISP/8.8.8.8)에 질의. 리졸버가 루트 → TLD(.com) → 권한 네임서버로 단계적으로 물어 최종 IP를 받아 클라에 돌려준다. 각 단계는 "다음에 누구한테 물어봐라"를 위임(referral)한다.
TTL: 각 레코드가 캐시될 수 있는 시간. 짧으면 변경 반영 빠름·질의 부하↑, 길면 부하↓·변경 반영 느림. 페일오버/배포 전엔 TTL을 미리 낮춘다.
레코드: A(IPv4), AAAA(IPv6), CNAME(별칭), SRV(서비스의 호스트+포트+우선순위·가중치).
지역 라우팅: GeoDNS(질의 출처 지역에 따라 다른 IP 응답), Anycast(같은 IP를 여러 곳에 광고해 BGP가 가까운 곳으로), latency 기반(실측 지연으로 최적지 선택).
DNS는 수십 초~분 단위 캐시·정적이라, 실시간 동적 서버 할당은 별도 매치메이킹 서버가 맡는다.

클라이언트는 OS 스텁 리졸버를 통해 재귀 리졸버(ISP 또는 8.8.8.8/1.1.1.1)에 login.mygame.com A?를 묻는다.
리졸버 캐시에 없으면 루트 네임서버에 묻는다 → 루트는 ".com은 이 TLD 서버들한테 물어봐" (referral).
TLD(.com) 네임서버에 묻는다 → "mygame.com의 권한 네임서버는 여기야" (NS 레코드).
권한(authoritative) 네임서버에 묻는다 → "login.mygame.com은 203.0.113.5" (A 레코드, 최종 답).
리졸버가 결과를 TTL 동안 캐시하고 클라에 반환. 다음 질의는 캐시에서 즉시.

핵심: 리졸버는 재귀적으로(끝까지 대신 알아봐 주고), 네임서버들은 반복적/위임적으로(다음 단계를 알려줄 뿐) 동작한다.

각 응답에 TTL(초)이 붙고, 리졸버·OS·앱이 그 시간 동안 캐시한다. 그래서 IP를 바꿔도 TTL이 지나기 전엔 옛 IP로 접속할 수 있다.
짧은 TTL(예: 30~60s): 변경 즉시 반영, 페일오버 빠름. 대신 질의 폭증·권한 서버 부하·약간의 추가 지연.
긴 TTL(예: 1h~1d): 캐시 적중률↑·부하↓·빠른 응답. 대신 IP 변경이 늦게 퍼짐.
배포 전략: 블루-그린/페일오버를 앞둔 도메인은 미리 TTL을 낮춰 두고, 전환 시 빠르게 갈아끼운다. (단, 일부 리졸버는 TTL을 무시하거나 최소값을 강제하므로 100% 보장은 아님 → 그래서 게임은 DNS만으로 페일오버하지 않고 클라 재접속 로직을 둔다.)

A: 이름 → IPv4. AAAA: 이름 → IPv6.
CNAME: 이름 → 다른 이름(별칭). cdn.mygame.com → mygame.cdnprovider.net. CNAME은 같은 이름에 다른 레코드와 공존 불가(루트 도메인에 못 씀 등 제약).
SRV: _service._proto.name → 우선순위, 가중치, 포트, 타깃 호스트. 즉 포트까지 알려주므로 "이 서비스는 어느 호스트의 어느 포트에 있다"를 DNS로 표현. 우선순위/가중치로 1차/백업·부하분산도 표현 가능. (게임에서 표준 포트가 아닐 때 서버 디스커버리에 유용.)

GeoDNS: 권한 네임서버가 질의 출처(리졸버) IP의 지역에 따라 다른 A 레코드를 응답. 한국 유저엔 서울 IP, 유럽 유저엔 프랑크푸르트 IP. 단순하지만 "리졸버 위치 ≠ 유저 위치"일 수 있고(공용 DNS 사용 시), TTL 캐시로 즉시성이 떨어진다.
Anycast: 같은 IP를 여러 데이터센터에서 BGP로 광고 → 인터넷 라우팅이 네트워크적으로 가까운 곳으로 보낸다. DNS 변경 없이 동작. 주로 DNS 서버 자체, CDN, 로그인 엔드포인트에 쓴다. UDP/짧은 트랜잭션엔 좋지만 장시간 TCP 세션은 경로 변경 시 끊길 수 있어 게임플레이 트래픽엔 주의.
Latency 기반 라우팅(예: AWS Route 53 latency policy): 실측 지연 데이터로 가장 빠른 리전을 응답. Geo보다 정확한 경우가 많다.
실무: 로그인/매치메이킹 엔드포인트는 GeoDNS/Anycast로 가까운 리전에 붙이고, 실제 게임 서버 IP:포트는 그 리전의 매치메이커가 동적으로 할당해 클라에 직접 통지한다.

게임 서버 인스턴스는 수시로 뜨고 죽고(오토스케일, 방 단위 생성/소멸), 한 IP에 여러 방/포트가 동적으로 매핑된다. DNS는 TTL 캐시 때문에 초 단위 동적 할당에 부적합하고, 포트·방 단위 라우팅·인원수 기반 배정 같은 게임 로직을 표현할 수 없다.
그래서 클라이언트는 안정적인 이름(로그인/매치 서버)에만 DNS로 접속하고, 그 서버가 현재 가용한 게임 인스턴스의 IP:포트를 동적으로 골라 직접 알려준다. DNS는 "안정적 진입점", 매치메이커는 "실시간 배정"으로 역할 분리.

"DNS는 항상 같은 IP를 준다" → GeoDNS·라운드로빈·latency 정책으로 질의자마다 다를 수 있다.
"TTL=0이면 캐시 안 됨이 보장" → 많은 리졸버가 최소 TTL을 강제하거나 음수 캐싱을 하므로 완전 즉시 반영은 아님.
"CNAME은 루트 도메인에도 쓸 수 있다" → 표준상 루트(zone apex)엔 CNAME 불가. (ALIAS/ANAME 같은 벤더 확장으로 우회.)
"Anycast면 세션이 항상 같은 서버로 간다" → 경로 변경 시 다른 노드로 갈 수 있어 stateful 장시간 세션엔 위험.
"DNS만으로 동적 게임 서버 할당 가능" → 캐시·정적 특성상 부적합. 매치메이커가 담당.

Q. DNS 라운드로빈 부하분산의 한계는? A. 여러 A 레코드를 번갈아 주지만, 헬스체크·가중치·세션 어피니티가 없어 죽은 서버 IP도 줄 수 있고 분산이 고르지 않다. 실무는 LB나 매치메이커로 보완.
Q. DNS는 UDP인가 TCP인가? A. 기본 UDP 53(응답이 512B/EDNS 한계 초과나 영역 전송 시 TCP). 최근 DoT(853/TCP)·DoH(443/HTTPS)로 암호화도.
Q. negative caching이란? A. "그런 이름 없음(NXDOMAIN)" 응답도 SOA의 최소 TTL만큼 캐시. 없는 서브도메인 반복 질의를 줄인다.
Q. 게임 클라가 DNS 대신 IP를 하드코딩하면? A. 페일오버/마이그레이션이 불가능해진다. 반드시 도메인 + 재접속 로직으로 유연성을 확보해야 한다.