DNS_시스템 설계 노트 3

一.DNS 란 무엇인가?

DNS(Domain Name System) 는인터넷의 전화번호부에 해당하며, 도메인 이름 (www.example.com) 을 IP 주소 (93.184.216.34) 로 번역할 수 있습니다:

Address book for all of internet.

기술적인 관점에서 보면, DNS 는 계층형 분산 데이터베이스에 몇 가지 기정 프로토콜을 더한 것 입니다. 데이터베이스의 조회 및 업데이트 메커니즘, 다른 서버 간 데이터베이스 정보의 복제 메커니즘, 그리고 데이터베이스 스키마 (Schema) 를 포함합니다

DNS architecture is a hierarchical distributed database and an associated set of protocols.

P.S.계층형 데이터베이스 외에, 관계형 데이터베이스와 망상 데이터베이스가 있습니다

二.DNS 의 유래

DNS 는 인터넷의 초기에서 유래했으며, 당시의 인터넷은 미국 국방부 (the United States Department of Defense) 가 연구 목적으로 구축한 소규모 네트워크였습니다. HOSTS 파일을 통해 네트워크 내 각 컴퓨터의 호스트 이름을 관리했으며, 이 HOSTS 파일은 집중 관리 서버에 놓여 있었고, 호스트 이름을 해결해야 하는 각 사이트는 이 파일을 먼저 다운로드해야 했습니다

네트워크 내 호스트 수의 증가에 따라, HOSTS 파일 업데이트 프로세스에서 발생하는 트래픽과 파일 크기 문제가 점차 드러났습니다. 이에 따라, 유연하게 확장할 수 있고 다양한 데이터 타입을 지원하는 분산 호스트 이름 관리 시스템의 구축이 기대되었으며, 인터넷의 중요한 인프라스트럭처가 되었습니다

이 새로운 분산 시스템이*DNS(Domain Name System)*입니다

P.S.최초의 DNS 사양은 RFC 882 와 RFC 883 이었으며, 후에 RFC 1034 와 RFC 1035 로 대체되었고, 이후의 관련 사양은 이를 기반으로 보안, 구현, 관리 등의 부분을 확장했습니다

三.기본 개념

도메인 이름

그 중에서, 각 부분에는 대응하는 이름이 있습니다:

루트 도메인 (Root domain): 나무의 뿌리, 이름 없는 레벨 1 을 나타냄. 예를 들어 www.example.com. 말미의 점
최상위 도메인 (Top-level domain): 국가, 지역 또는 조직 타입을 나타내는 데 사용. 예를 들어 .com, .edu
두 번째 레벨 도메인 (Second-level domain): 길이가 고정되어 있지 않으며, 개인 또는 조직에 의해 등록됨. 예를 들어 example.com. 중의 example 부분
서브도메인 (Subdomain): 두 번째 레벨 도메인에서 파생되며, 두 번째 레벨 도메인을 보유한 조직/개인에 의해自行 생성. 예를 들어 www.example.com
호스트 이름/리소스 이름 (Host or resource name): 트리 구조의 잎. 예를 들어 api.aws.amazon.com 중 가장 왼쪽의 api

P.S.또한, 도중의 FQND 는 정규화된 도메인 이름 (Fully Qualified Domain Name) 을 지칭하며, 호스트 이름과 도메인 이름으로 구성되며, 트리 구조 내 호스트의 위치를 유일하게 식별할 수 있습니다

최상위 도메인은 DNS 를 관리하는 도메인 이름 등록 기관에 의해 유지되며, 국가 또는 지역에 따라 각 조직에 할당됩니다. 예를 들어:

.com: 상업 조직 (Commercial organizations)
.edu: 교육 기관 (Educational institutions)
.org: 비영리 조직 (Non-profit organizations)
.net: 네트워크 서비스 제공자 (Networks (the backbone of the Internet))
.gov: 비군사적 정부 조직 (Non-military government organizations)
mil: 군사적 정부 조직 (Military government organizations)
arpa: 리버스 DNS (Reverse DNS)
.**: 두 글자의 국가 코드. 예를 들어 .us, .au, .ca, .fr

mydomain.microsoft.com.(말미 점.은 루트 도메인을 나타냄) 을 예로:

리소스 레코드

리소스 레코드 (resource record, 약칭 RR) 가 DNS 데이터베이스를 구성하며, 일반적으로 다음과 같은 종류가 있습니다:

A 레코드 (Address record): 주소 레코드. 도메인 이름을 IP 주소로 향함
AAAA 레코드 (IPv6 address record): IPv6 주소 레코드. IPv6 를 지원하는 A 레코드에 해당
CAA 레코드 (Certification Authority Authorization): 인증 기관 승인 레코드. 어떤 CA 기관이 도메인에 인증서를 발급하는 것을 허용하는지 지정하는 데 사용
CNAME 레코드 (Canonical name record): 별명 레코드. 한 도메인 이름을 다른 도메인 이름, 또는其它의 CNAME 레코드, A 레코드로 향함
MX 레코드 (Mail exchange record): 메일 교환 레코드. 메시지를 수신하는 메일 서버를 지정. 여러 개의 메일 서버가 있는 경우, 각각의 우선순위를 지정 가능
NAPTR 레코드 (Naming Authority Pointer): 정규식을 통해 도메인 이름을 매칭 및 치환하는 것을 허용. 예를 들어 네트워크 전화 시스템이 사용자가 입력한 전화번호를 SIP URI 로 변환
NS 레코드 (Name server record): 도메인 이름 서버 레코드. 도메인 이름과 서브도메인 이름의 해결에 사용하는 DNS 서버를 지정
PTR 레코드 (PTR Resource Record): PTR 레코드. IP 주소를 도메인 이름으로 향함. CNAME 과의 차이는 직접 종료하고 결과를 반환하는 것으로, 주로 리버스 해결 (IP 를 통한 도메인 이름 역조회) 에 사용
SOA 레코드 (Start of authority record): DNS 권한 정보를 지정. 주 도메인 이름 서버, 도메인 관리자의 메일박스, 도메인 시리얼 번호 등을 포함
SPF 레코드 (Sender Policy Framework record): 발신자 정책 프레임워크 레코드. 초기에는 메일 발신자의 신원을 검증하는 데 사용되었으나, 폐기되었으며, TXT 레코드로 대체할 것을 권장
SRV 레코드 (Service locator record): 범용 서비스 로케이터 레코드. 서비스가 위치한 서버 (도메인 이름과 포트 번호) 를 지정. 주로 SIP(Session Initiation Protocol, 세션 개시 프로토콜) 에 사용
TXT 레코드 (Text record): 텍스트 레코드. 문자열에 사용

그 중에서, CAA 레코드는 인증서 보안 메커니즘의 일종으로, CA 기관은 인증서를 발급할 때 CAA 레코드를 확인하며, 승인되지 않은 경우 해당 도메인에 대한 인증서 발급을 ��부합니다. 자세한 내용은 DNS Certification Authority Authorization 참조

주의, NS 레코드와 SOA 레코드는 이해하기 어렵고, DNS 의 구조와 관련이 있습니다. 자세한 내용은 후문의 구조 부분 참조

P.S.기타 수백 종의 DNS 레코드 타입에 대해서는, List of DNS record types 참조

예를 들어:

# A 기록
$ dig -t A ayqy.net
ayqy.net.		600	IN	A	121.42.135.10

# CNAME 기록
$ dig -t CNAME www.baidu.com
www.baidu.com.		600	IN	CNAME	www.a.shifen.com.

# NS 기록
$ dig -t NS ayqy.net
ayqy.net.		86400	IN	NS	dns10.hichina.com.
ayqy.net.		86400	IN	NS	dns9.hichina.com.

# MX 기록
$ dig -t MX ayqy.net
ayqy.net.		600	IN	MX	10 mxw.mxhichina.com.
ayqy.net.		600	IN	MX	5 mxn.mxhichina.com.

P.S.그 중에서 두 번째 열은 위에서 언급한 캐시 관련 TTL(Time-to-Live) 값이며, 단위는 초

라우팅 정책

기본적인 매핑 규칙 외에, DNS 서비스는 몇 가지 라우팅 정책을 지원할 수 있습니다. 예를 들어:

가중치 기반 라우팅 정책 (Weighted routing policy): 지정된 가중치 값에 따라 우선순위로 트래픽을 배포. A/B 테스트, 블루 - 그린 배포 등의 시나리오에 사용 가능
지연 기반 라우팅 정책 (Latency routing policy): 지연 상황에 따라 도메인 이름을 해결. 예를 들어 지연이 최소인 IP 선택
지리적 위치 기반 라우팅 정책 (Geolocation routing policy): 사용자의 지리적 위치 (각국, 각 대주 등) 에 따라 도메인 이름을 해결
지리적 위치 근접도 기반 라우팅 정책 (Geoproximity routing policy): 사용자의 소재지와 타겟 리소스의 소재지의 근접도에 따라 도메인 이름을 해결
페일오버 라우팅 정책 (Failover routing policy): 액티브 - 패시브 페일오버 모드 에 사용. 하나의 IP 에 문제 발생 후 다른 IP 로 전환
다중 값 응답 라우팅 정책 (Multivalue answer routing policy): 간단한 DNS 레이어 로드 밸런싱. 1 대 다 매핑 설정 가능. 그 중에서 랜덤으로 선택

P.S.라우팅 정책에 대한 자세한 내용은, 트래픽 정책 생성 및 관리 참조

四.구조

DNS 도메인 스페이스는 존 (Zone) 으로 분할되어 관리되며, 존은 DNS 서버의 관할 범위에 해당합니다

존

하나의 DNS 데이터베이스는 여러 개의 존으로 분할되며, 각 존은 도메인 스페이스 내의 연속된 부분의 리소스 레코드와 그 owner 정보를 포함하며, 형성되는*존 파일 (Zone files)*은 DNS 서버에 의해 유지되며, 하나의 DNS 서버는 0 개에서 여러 개의 존을 관리할 수 있습니다

각 존은 특정 도메인 이름에 대응하며, 해당 존의 루트 도메인 (Root domain) 이라고 하며, 존에는 존의 루트 도메인으로 끝나는 모든 도메인 이름 정보가 포함됩니다. 존 파일 내의 첫 번째 레코드는 SOA(Start of Authority) 리소스 레코드로, 해당 존 내의 최상의 정보원인 주 DNS 도메인 이름 서버, 및 정보 업데이트와 관련된 몇 가지 타이머 (Refresh Interval, Expire Time 등) 를 식별합니다

위임

존 내의 도메인 이름은 다른 DNS 서버 상에 있는 다른 존에 위임할 수 있습니다. *위임 (Delegation)*은 DNS 스페이스의 일부를 다른 DNS 서버가 담당하도록 하는 프로세스로, 예를 들어 다른 조직, 부서 또는 워크그룹입니다. 이 위임 관계는 NS 리소스 레코드를 통해 식별되며, 레코드 내에는 위임된 존과 그에 대응하는 권한 서버의 도메인 이름이 지정됩니다

크로스 존 위임은 DNS 의 최초의 설계 목표 중 하나로, 다음을 충족하기 위해:

하나의 DNS 도메인의 관리 작업을 여러 조직 또는 부서에 위임
큰 DNS 데이터베이스의 유지 작업을 여러 DNS 서버에 분산하여, 도메인 이름 해결 성능과 내결함성 향상
조직 소속 관계에 따라, 호스트를 적절한 도메인 아래에 배치

크로스 존으로 도메인 이름을 해결해야 할 때, NS 레코드 내의 타겟 존의 DNS 서버에 문의합니다

예를 들어, microsoft.com. 은 microsoft.com 과 mydomain.microsoft.com 두 개의 존 관리에 위임되었습니다:

五.구현 원리

복제 메커니즘

도메인 스페이스 내의 동일 부분은 여러 개의 존으로 나타낼 수 있으며, 다음과 같이 나뉩니다:

주 존 (Primary)
보조 존 (Secondary)
스텁 존 (Stub)

존 하의 모든 레코드의 업데이트는 주 존에서 발생하며, 보조 존과 스텁 존은 모두 읽기 전용인 주 존의 복사본으로, 차이는 스텁 존이 권한 서버 (이 세 가지 존을 호스트하는 DNS 서버) 를 식별하기 위한 레코드만 포함한다는 것입니다. 주 존을 호스트하는 DNS 서버는 해당 존의 주 DNS 서버이며, 보조 존을 호스트하는 DNS 서버는 보조 DNS 서버입니다

주 DNS 서버 (또는 보조 DNS 서버) 상의 존 파일은 여러 개의 DNS 서버에 복제될 수 있으며, 이 프로세스는*존 전송 (Zone transfer)*이라고 하며, 전송 방식은 2 종류로 나뉩니다:

푸시: 주 DNS 서버는 존 파일이 변화했을 때, 하나 또는 여러 개의 보조 DNS 서버에 알림
풀: 보조 DNS 서버 상의 DNS 서비스가 시작되었을 때, 및 존 파일의 갱신 간격이 만료되었을 때, 보조 서버는 적극적으로 주 DNS 서버에 변화를 문의

전송되는 데이터 양에 따라 다음과 같이 나뉩니다:

전체: AXFR(A Full Zone Transfer). 모든 레코드를 전송
증분: IXFR(incremental zone transfer). 변경된 레코드만 전송

조회 메커니즘

DNS 조회는 DNS 클라이언트와 DNS 서버, 및 두 개의 DNS 서버 간에 발생하며, 일반적으로 특정 도메인 이름의 일련의 레코드를 한 번에 조회합니다. 예를 들어 그 모든 A 레코드

구체적으로, DNS 조회는 2 종류로 나뉩니다:

재귀 조회 (Recursive): DNS 서버는 관련 있는其它의 DNS 서버에 연락해야 함
반복 조회 (Iterative): DNS 서버는 로컬 데이터에 기반하여 응답하며,如果真的로 해결할 수 없는 경우, 부정 응답을 반환

전자는 주로 DNS 클라이언트 (DNS 리졸버 등) 와 DNS 전달 서비스에 사용되며, 로컬 데이터 (로컬 존 파일 및 이전 조회 결과의 캐시) 만으로는 해결할 수 없는 경우, 루트 DNS 서버로 상승합니다 (전달 서비스는 먼저 소스 서버로 상승). 후자는 주로 DNS 서비스가 그 도메인 외의 도메인 이름을 조회할 때 사용되며, 이 때 여러 개의 외부 DNS 서버에 문의해�� 해결할 수 있을 수 있습니다

www.whitehouse.gov 를 예로:

구체적인 조회 프로세스는 다음과 같습니다:

클라이언트가 로컬 DNS 서버에 재귀 조회 (A 레코드) 를 시작
로컬 DNS 서버가 루트 DNS 서버에 반복 조회 (A 레코드) 를 시작
루트 DNS 서버가 .gov 도메인 이름 서버의 참조 (A 레코드) 를 반환
로컬 DNS 서버가 .gov 도메인 이름 서버에 반복 조회 (A 레코드) 를 시작
.gov 도메인 이름 서버가 whitehouse.gov 도메인 이름 서버의 참조 (NS 레코드) 를 반환
로컬 DNS 서버가 whitehouse.gov 도메인 이름 서버에 반복 조회 (A 레코드) 를 시작
whitehouse.gov 도메인 이름 서버가 반복 조회에 응답 (www.whitehouse.gov 의 IP 주소)
로컬 DNS 서버가 최초의 재귀 조회에 응답 (www.whitehouse.gov 의 IP 주소)

P.S.그 중에서, 참조 (DNS Referral) 는간접적인 답을 가리킵니다:

DNS Referrals. The term referral indicates a response to a query which does not contain an answer section (it is empty) but which contains one or more authoritative name servers (in the Domain Authority section) that are closer to the required query question.

자세한 내용은 DNS Referrals 참조

캐시 메커니즘

리소스 레코드 내의 TTL(Time-to-Live) 값은 해당 레코드의유효 기간에 해당하며,其它의 DNS 서버는 TTL 에 기반하여 이 정보를 얼마나 캐시할지 결정합니다. 만약 레코드가 자신의 TTL 을 지정하지 않은 경우, DNS 서버는 SOA 레코드에서 기본 TTL 을 상속하며,其它의 DNS 서버가 리소스 레코드를 확장 캐시하는 것을 방지합니다

클라이언트의 DNS 리졸버도 수신한 DNS 조회 결과를 캐시하며, 캐시 기간도 TTL 을 따릅니다. DNS 서버는 캐시로 조회에 응답할 때, 캐시의 TTL 을 전달하며, 수신 측은 수신한 TTL 값을 기준으로 하며 (자신의 TTL 로 리셋하지 않음), 리소스 레코드가 정상적으로 만료되는 것을 보장합니다

TTL 을 설정할 때는, 캐시 정보의 정확성, 및 DNS 서버의 효용과 네트워크 트래픽 문제를 고려할 필요가 있으며, 이 둘은 조금 충돌합니다. 만약 TTL 이 너무 짧으면, 오래된 정보가 나타날 가능성은 감소하지만, DNS 서버의 효용 문제와 트래픽 문제가 나타나고, TTL 이 너무 길면, 캐시 정보가 오래될 수 있으며, 리졸버가 잘못된 결과를 반환할 가능성을 의미하지만, 효용 문제와 트래픽 문제를 경감할 수 있습니다

P.S.DNS 캐시 및 업데이트에 대한 자세한 내용은, DNS Processes and Interactions 참조

이로써, DNS 의 안팎이 모두 명확해졌습니다