도메인 계층루트 도메인Top-Level Domain(TLD)DNS 동작 방식DNS에서 알아두면 좋은 내용도메인 위임(DNS Delegation)TTL(Time To Live)GSLBGSLB 동작 방식GSLB 분산 방식
도메인 주소를 IP 주소로 변환하는 역할을 함. MSA 기반의 설계가 많아지면서 다수의 API를 이용하다보니 사용자의 호출 뿐 아니라 서비스 간 API 호출이나 인터페이스가 많아져 DNS의 역할이 더 중요해졌음
도메인 계층

루트 도메인
- 도메인을 구성하는 최상위 영역
- DNS 서버는 사용자가 쿼리한 도메인에 대한 값을 직접 갖고 있거나 캐시에 저장된 정보를 이용해 응답함
- 만약 DNS 서버에 해당 도메인의 정보가 없으면 루트 도메인을 관리하는 루트 DNS에 쿼리하게 됨
- 루트 DNS(서버)는 전 세계에 13개가 있고 dns서버를 설치하면 루트 DNS의 IP주소를 기록한 힌트 파일을 가지고 있어 루트 DNS 관련 정보를 별도로 설정할 필요 없음
Top-Level Domain(TLD)
6가지 유형으로 구분 가능함
전체 리스트는 IANA 사이트(https://www.iana.org/domains/root/db) 에서 확인가능함
- Generic TLD(gTLD)
- .com, .edu, .gov, .int, .mil, .net, .org
- …
- Second-Level Domain(SLD)
- Third-Level Domain(3LD)
DNS 동작 방식
- 도메인을 쿼리하면 DNS 서버에 쿼리하기 전 로컬에 있는 DNS 캐시 정보를 먼저 확인함
- 기존 DNS 조회를 통해 확인한 동적 DNS 캐시
- hosts 파일(로컬에서 도메인과 ip 주소를 관리하는 파일)에 저장되어 있는 정적 DNS 캐시
- 윈도에서 dns 캐시 확인 명령 — ipconfig /displaydns
- 전 세계의 도메인 정보를 DNS 서버 하나에 저장할 수는 없기에 분산된 데이터베이스로 서로 도와주도록 설계되어 있음
- 그래서 자신이 가진 도메인 정보가 아니면 다른 DNS에 질의해 결과를 받음
- DNS 기능을 서버에 올리면 DNS 서버는 기본적으로 루트 DNS 관련 정보를 가지고 있음

- 사용자 호스트는 ‘zigispace.net’이라는 도메인 주소의 IP 주소가 로컬 캐시에 저장되어 있는지 확인
- ‘zigispace.net’이 로컬 캐시에 저장되어 있지 않으면 사용자 호스트에 설정된 DNS에 ‘zigispace.net’에 대해 쿼리함
- DNS 서버는 ‘zigispace.net’이 로컬 캐시와 자체에 설정되어 있는지 직접 확인하고 없으면 해당 도메인을 찾기 위해 루트 NS(Name Server)에 .net에 대한 TLD 정보를 가진 도메인 주소를 쿼리함
- 루트 DNS는 ‘zigispace.net’의 TLD인 ‘.net’을 관리하는 TLD 네임 서버 정보를 DNS 서버에 응답함
- DNS는 TLD 네임 서버에 ‘zigispace.net’에 대한 정보를 다시 쿼리함
- TLD 네임 서버는 ‘zigispace.net’에 대한 정보를 가진 zigi 네임 서버에 대한 정보를 DNS 서버로 응답함
- DNS는 zigi 네임 서버에 ‘zigispace.net’에 대한 정보를 쿼리함
- zigi 네임 서버는 ‘zigispace.net’에 대한 정보를 DNS 응답함
- DNS는 ‘zigispace.net’에 대한 정보를 로컬 캐시에 저장하고 사용자 호스트에 ‘zigispace.net’에 대한 정보를 응답함
- 사용자 호스트는 DNS로부터 받은 ‘zigispace.net’에 대한 IP 정보를 이용해 사이트에 접속함
DNS에서 알아두면 좋은 내용
도메인 위임(DNS Delegation)
도메인은 그 도메인에 대한 정보를 관리할 수 있는 네임 서버를 지정하지만 도메인 내의 모든 레코드를 그 네임 서버가 직접 관리하지 않고 일부 영역에 대해서는 다른 곳에서 레코드를 관리하도록 위임하기도 함. 이 방식을 도메인 위임이라고 함
CDN을 이용하거나 GSLB를 사용하는 것이 대표적인 경우임
TTL(Time To Live)
DNS에 질의해 응답받은 결과값을 캐시에서 유지하는 시간을 의미함
GSLB
DNS에서 동일한 레코드 이름으로 서로 다른 IP 주소를 동시에 설정할 수 있는데, 이를 이용하여 도메인 질의에 따라 응답받는 IP 주소를 나누어 로드밸런싱이 가능함 = DNS 로드밸런싱
그러나, DNS에 저장된 레코드와 매핑된 서비스가 문제가 있어서 응답을 줄 수 없는 경우에도 DNS는 그냥 그 IP를 반환하게 됨(Health check 안함) → GSLB를 이용!
- GSLB는 DNS와 동일하게 도메인 질의에 응답해주는 역할과 동시에 로드 밸런서처럼 등록된 도메인에 연결된 서비스가 정상적인지 헬스 체크를 수행함
GSLB 동작 방식

- 사용자가 web.zigispace.net에 접속하기 위해 DNS에 질의
- LDNS는 web.zigispace.net을 관리하는 NS 서버를 찾기위해 root 부터 순차 질의함
- zigispace.net을 관리하는 NS 서버로 web.zigispace.net에 대해 질의함
- DNS 서버는 GSLB로 web.zigispace.net에 대해 위임했으므로 GSLB 서버가 NS 서버라고 LDNS에 응답함
- LDNS는 다시 GSLB로 web.zigispace.net에 대해 질의함
- GSLB는 web.zigispace.net에 대한 IP 주솟값 중 현재 설정된 분산 방식에 따라 서울 또는 부산 데이터 센터의 IP 주소값을 DNS에 응답함(헬스 체크, 부하 분산 방식 이용. 본예제는 서울 IP를 응답하는 것으로 가정)
- GSLB에서 결과값을 응답받은 LDNS는 사용자에게 web.zigispace.net이 1.1.1.1로 서비스하고 있다고 최종 응답함
GSLB 분산 방식
- 아래와 같은 주요 목적 달성가능함
- 서비스 제공의 가능 여부를 체크해 트래픽 분산
- 지리적으로 멀리 떨어진 다른 데이터 센터에 트래픽 분산
- 지역적으로 가까운 서비스에 접속해 더 빠른 서비스 제공이 가능하도록 분산
- GSLB에서 지원되는 분산 방식은 GSLB 장비를 생산하는 벤더, 모델에 따라 조금씩 다를 수 있찌만 대부분 다음 두 가지 헬스 체크 모니터링 요소를 지원함
- 서비스 응답 시간/지연 (RTT/Latency) — 서비스 요청에 대한 응답이 얼마나 빠른지 또는 지연이 얼마나 없는지를 확인하고 이것을 이용해 서비스 분산처리
- IP에 대한 지리 정보 — 서비스 제공이 가능한 각 사이트의 IP 주소에 대한 Geo 값을 확인해 가까운 사이트로 서비스 분산을 처리함