# DNS

* 데이터 프로토콜
  * 실제 데이터를 포함하는 프로토콜
* 컨트롤 프로토콜
  * 통신에 직접 관여하지 않지만, 첫 통신 관계를 맺거나 유지하는 데에 필요한 프로토콜
  * TCP/IP 프로토콜 스택에서는 ARP, ICMP, DNS가 주요 컨트롤 프로토콜이다.

## 개념

* Domain Name System
* 도메인 주소를 IP 주소로 변환한다.
* 실제로 패킷을 만들어 통신하려면 3계층 IP 주소를 알아야 하므로 도메인 주소를 IP 주소로 변환하는 DNS가 필요하다.

## 도메인 주소

### 필요성

* 숫자로 구성된 IP 주소보다 의미있는 문자열로 구성된 도메인 주소가 사람이 인식하기에 훨씬 용이하므로, 대부분의 웹사이트는 도메인 주소 기반으로 운영된다.
* 내부 시스템의 서비스 간 연결에도 도메인 주소를 사용한다. IP 주소를 통해 서비스 간 연결을 맺을 경우 IP 변경 시 여러 가지 설정을 변경하거나 프로그램을 재배포해야 하는 경우가 발생한다. 하지만 도메인 주소를 사용하면 DNS 서버의 설정만 변경하면 된다.
* 보통 인터넷 연결을 위한 DNS와 내부 서비스 통신을 위한 DNS를 별도로 운영한다.

### 구조

* 도메인은 역트리 계층 구조이므로 최상위 루트부터 하위 레벨까지 단계적으로 원하는 주소로 찾아간다.
* 각 계층은 `.` 으로 구분되며 뒤에서 앞으로 해석한다.
* 최대 128계층까지 구성 가능하며 각 계층마다 최대 63바이트까지 사용할 수 있다. 구분자 `.`를 포함한 전체 도메인 이름 길이는 255바이트까지 사용 가능하다.
* 알파벳, 숫자, `-` 만 사용 가능하다.

<figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2FbFjpdz8ziHTjRcRiHFcP%2Fimage.png?alt=media&#x26;token=b1cb7b2f-1e26-47ab-bc61-fdaf00181fdf" alt=""><figcaption></figcaption></figure>

* 루트 도메인은 도메인을 구성하는 최상위 영역이다. DNS 서버에 도메인에 해당하는 데이터가 없다면 루트 DNS 서버에 조회 요청을 보낸다.
* 최상위 도메인인 TLD는 다음과 같은 유형으로 분리된다.
  * Generic TLD
    * 특별한 제한없이 일반적으로 사용되는 도메인이며 세 글자 이상으로 구성된다.
    * `com` , `edu`, `gov`, `int`, `mil`, `net`, `org`
  * Country Code TLD
    * 국가별 최상위 도메인이며 두 글자의 국가 코드를 사용한다.
    * `co.kr`, `com.au`, ...
  * Sponsored TLD
    * 특정 목적을 위한 스폰서를 두고 있는 최상위 도메인이다.
    * `aero`, `asia`, ...
  * Infrastructure
    * 중요한 인프라 식별자 공간을 지원하기 위해 전용으로 사용되는 최상위 도메인이다.
    * `arpa`
    * `.IN-ADDR.ARPA` 의 경우 이 도메인의 하위 도메인으로, IPv4 주소를 도메인 이름에 매핑하는 역방향 도메인에서 사용한다.
  * Generic-restricted
    * 특정 기준을 충족하는 사람이나 단체가 사용할 수 있다.
    * `biz`, `pro`, ...
  * Test
    * 테스트 목적으로 사용하는 최상위 도메인이다.
    * `test`

## 동작 방식

* 도메인을 쿼리하면 DNS 서버에 쿼리하기 전 로컬에 있는 DNS 캐시 정보를 확인한다.
* DNS 캐시에 데이터가 없다면 DNS 서버에 쿼리를 보내 응답을 DNS 캐시에 저장한다.
* DNS 캐시 정보는 기존에 DNS 조회를 통해 확인한 동적 DNS 캐시와 hosts 파일에 저장된 정적 DNS 캐시로 구성된다.
* DNS 서버는 분산된 데이터베이스 형태로 동작한다.
* DNS 서버는 기본적으로 루트 DNS에 대한 정보를 갖고 있으며, 클라이언트의 쿼리가 자신에게 없는 정보이면 루트 DNS에 쿼리하여 도메인의 TLD 값을 확인해 해당 TLD 값을 관리하는 DNS를 응답한다.
* 처음 질의를 받은 DNS가 루트 DNS부터 시작하여 상위 DNS에 쿼리를 보내 결괏값을 알아낸 후 최종 결과를 클라이언트에 응답한다.
  * 재귀적 쿼리 : 쿼리를 보낸 클라이언트에 서버가 최종 결괏값을 반환하는 서버 중심 쿼리, 클라이언트와 로컬 DNS 간의 쿼리를 의미한다.
  * 반복적 쿼리: 최종 값을 받을 때 까지 클라이언트에서 쿼리를 계속 진행하는 방식, 로컬 DNS 서버와 상위 DNS 구간의 쿼리를 의미한다.

<figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2FkRLtUEu115vfnhVj7TKP%2Fimage.png?alt=media&#x26;token=081c9324-a88d-4860-bf19-de5082622944" alt=""><figcaption></figcaption></figure>

### 마스터 / 슬레이브

* 마스터, 슬레이브 서버 모두 도메인 쿼리에 응답한다.
* 마스터 서버는 도메인에 대한 Zone 파일을 직접 생성해 도메인 관련 정보를 관리한다.
* 슬레이브 서버는 마스터에 만들어진 Zone 파일을 복제한다. (Zone Transfer)
* 마스터 서버로부터 인가받지 않은 다른 DNS 서버가 정보를 복제하지 않도록 복제 가능한 슬레이브 서버 정보를 입력해야 한다.
* 마스터 서버에 문제가 발생했을 때에는 슬레이브 서버도 도메인에 대한 질의를 정상적으로 처리할 수 없기 때문에, 만료 시간 안에 마스터 서버를 복구하거나 슬레이브 서버를 마스터로 전환해야 장애를 막을 수 있다.
* 모든 도메인에 대해 일괄적으로 마스터/슬레이브 서버를 설정하는 것이 바람직하다.

## 주요 레코드

* 도메인에는 다양한 내용을 매핑할 수 있는 레코드가 있다.

#### A(IPv4)

* 도메인 주소를 IP 주소로 변환하는 레코드
* 동일한 도메인을 가진 A 레코드를 여러 개 만들어 서로 다른 IP 주소와 매핑할 수 있다.
* 다수의 도메인에 동일한 IP를 매핑하고 HTTP 헤더의 HOST 필드에 도메인을 명시해 하나의 웹 서버에 여러 서비스를 구분해 제공할 수도 있다.

#### AAAA(IPv6)

* A 레코드와 동일하지만 IPv6 주소 쳬계에서 사용된다.

#### CNAME

* Canonical Name
* 별칭 이름을 사용하게 해주는 레코드이다.
* `www.naver.com`을 `naver.com`으로 매핑하여 IP 주소가 변경될 때 `naver.com`에 매핑된 주소만 변경하면 된다.

#### SOA

* Start of Authority
* 도메인 영역에 대한 권한을 나타내는 레코드이다.
* 현재 네임 서버가 이 도메인 영역에 대한 관리 주체임을 의미한다.
* 도메인 영역 선언 시 SOA 레코드를 반드시 만들어야 한다.
* 현재 도메인 관리에 필요한 속성값을 설정할 수 있다. 도메인 동기화에 필요한 타이머 값, TTL 값, 도메인 네임 서버, 관리자 정보를 설정한다.

#### NS

* Name Server
* 도메인에 대한 권한이 있는 네임 서버 정보를 설정하는 레코드이다.

#### MX

* Mail eXchange
* 메일 서버를 구성할 때 사용되는 레코드이다.
* 도메인을 메일 주소로 갖는 메일 서버를 선언한다.
* 다수의 MX 레코드를 선언해 우선 순위가 높은 서버로 메일을 보내보고, 실패 시 다음 순서의 서버로 보낼 수 있다.

#### PTR

* Pointer
* IP 주소에 대한 질의를 도메인 주소로 응답하기 위한 레코드이다.
* 즉, A 레코드가 정방향 조회용 레코드라면 PTR 레코드는 역방향 조회용 레코드이다.
* 하나의 IP 주소에 대해 하나의 도메인 주소만 가질 수 있다.
* 주로 화이트 도메인 구성용으로 사용된다.

#### TXT

* 도메인에 대한 설명 같은 텍스트를 입력하기 위한 레코드이다.
* 255자까지 사용할 수 있으며, 주로 화이트 도메인을 위한 SPF 레코드로 사용된다.

## 도메인 위임

* 보통 도메인에 대한 정보를 관리할 수 있는 네임 서버를 지정하지만, 도메인 내의 모든 레코드를 그 네임 서버가 직접 관리하지 않고 일부 영역에 대해서는 다른 곳에서 레코드를 관리하도록 위임할 수 있다.
* 대표적으로 CDN이나 GSLB를 사용한다.
* 특정 계층의 레코드를 위임하면 해당 레코드의 하위 계층은 함께 위임 처리된다.
  * 예를 들어 blog.naver.com에 대한 레코드만 위임하더라도 section.blog.naver.com 도 함께 위임 처리된다.

<figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2FCIzuPybPv0zfWK4c74kF%2Fimage.png?alt=media&#x26;token=11719350-0454-4f6b-afd7-a1958017418d" alt=""><figcaption></figcaption></figure>

## TTL

* DNS에 질의해 응답받은 결괏값을 캐시에서 유지하는 시간
* DNS에 설정된 TTL 값에 따라 그 시간 동안만 로컬 캐시에 저장한다.
* TTL이 너무 짧으면 DNS 정보 갱신이 빨라져 DNS 서버에 부하가 늘어나고, TTL이 너무 길면 도메인 정보가 변경되었을 때 정보 갱신이 지연된다.
* 리눅스의 경우 기본 DNS TTL 값이 3시간이다.
* DNS TTL 외에도 다양한 시간 설정을 SOA 레코드에 정의할 수 있다.
  * **refresh**(새로 고침 간격): 보조 네임 서버에서 Zone Transfer를 통해 정보를 주기적으로 받아오는 주기
  * **retry**(다시 시도 간격): 보조 네임 서버가 주 네임 서버로 접근이 불가능할 때 재시도하는 주기
  * **expire**(다음 날짜 이후 만료): 보조 네임 서버가 주 네임 서버로부터 도메인 정보를 받아오지 못할 때 유지되는 시간. 해당 시간 동안 도메인 관련 정보를 받아오지 못하면 주 네임 서버에서 삭제된 것으로 간주하고 보조 네임 서버에서도 해당 도메인 정보를 삭제

### 화이트 도메인

* 정상적으로 발송하는 대량의 이메일이 비정상으로 간주되어 차단되는 것을 막기 위해, 사전에 등록된 개인이나 사업자에 한해 국내 주요 포탈 사이트로의 이메일 전송을 보장해주는 제도이다.
* 불법 스팸메일 발송 사이트들은 실시간 블랙리스트(RBL, Realtime Blackhole List) 정보로 관리된다.
* 화이트 도메인을 등록하려면 도메인에 SPF 레코드를 설정해 등록해야 한다.
* SPF 레코드에 메일 서버 정보를 공개하면 수신 측 메일 서버에서는 해당 도메인을 통해 발송된 메일이 실제 메일 서버에 등록된 정보와 일치하는지 확인할 수 있다. 메일 정보와 도메인의 SPF 정보가 일치하지 않는다면 비정상적인 메일로 간주하며 된다.
* SPF 레코드의 길이는 최대 512bytes이므로, 하나의 도메인에 화이트 도메인으로 등록할 수 있는 메일 서버의 개수가 제한되어 있다. 길이가 초과되면 작성된 값들이 모두 지워지므로 주의해야 한다.

```
Domain. IN TXT "v=spf1 ip4:x.x.x.x -all"
```

### 한글 도메인

* 한글을 “퓨니코드”로 변경하고 이 퓨니코드로 DNS에 도메인을 생성하여 한글 도메인을 만들 수 있다.
* 퓨니코드란, 다국어 문자 셋으로부터 온 코드 포인트들을 기본적인 문자열(영숫자, 하이픈)들로 유일하게 표현한 것이다. 영어 이외의 문자를 사용해 도메인을 사용할 수 있도록 해주는 표준 코드이다.

## GSLB

* Global Server/Service Load Balancing
* 서비스 헬스 체크를 통해 안정적으로 도메인 질의 요청을 수행하도록 하고, 서로 다른 사이트로 트래픽을 분산시킬 수 있다.

### 필요성

* DNS에서 동일한 레코드 이름으로 서로 다른 IP 주소를 동시에 설정하면 DNS 요청을 로드밸런싱할 수 있다.
* 하지만 서비스 상태의 정상 여부를 확인하지 않고 도메인에 대한 질의를 하게 된다.
* GSLB는 등록된 도메인에 연결된 서비스가 정상적인지 헬스 체크를 수행하여 정상 상태인 레코드만 사용한다.

<figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2FMjZHGsP8Ky8NaFCyyB0r%2Fimage.png?alt=media&#x26;token=4d727609-4147-4808-92c2-33d8033974d5" alt=""><figcaption></figcaption></figure>

### 구성 방식

* 도메인 자체를 GSLB로 사용
  * GSLB를 도메인의 네임 서버로 사용한다.
  * 도메인에 대한 권한을 갖는 네임 서버를 GSLB로 지정하여 도메인에 대한 모든 레코드를 등록해 처리한다.
  * 모든 레코드에 대한 질의가 GSLB를 통해 이뤄지므로 GSLB에 부하가 갈 수 있다.
* 도메인 내의 특정 레코드만 GSLB를 사용
  * GSLB를 사용하려는 레코드에 대해서만 GSLB로 처리하도록 설정한다.
  * 특정 레코드에 대해서만 GSLB로 처리를 이관하는 방식을 사용한다.
    *   별칭(Alias) 사용 (CNAME 레코드 사용)

        * 실제 도메인과 다른 별도의 도메인 레코드로 GSLB에 등록한다.
        * CNAME 레코드의 값으로 GSLB가 네임 서버로 등록된 도메인을 등록해두어, 최종적으로 GSLB에 재질의되도록 한다.
        * CDN처럼 GSLB를 운영해주는 외부 사업자가 있거나 GSLB를 사용해야 하는 도메인이 매우 많은 경우, 별도의 GSLB를 운영하기 위해 사용한다.
        * 아래 예시를 보면 다음과 같은 순서로 DNS를 찾는다.
          * LDNS는 일단 도메인 이름을 기준으로 DNS 서버에 질의하여 CNAME 레코드를 확인한다.
          * CNAME으로부터 얻은 도메인 이름은 GSLB가 관리하므로, GSLB 도메인 이름에 대한 질의를 GSLB 서버에 보낸다.
          * GSLB에서 최종적으로 IP를 응답한다.

        <figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2F4IJ3ZJ4gVWNaGIiIDEBn%2Fimage.png?alt=media&#x26;token=1901fc71-1a58-4eb5-9fca-5fccd8287302" alt=""><figcaption></figcaption></figure>
    *   위임(Delegation) 사용 (NS 레코드 사용)

        * 실제 도메인과 동일한 도메인 레코드를 사용하며 도메인 전체를 위임한다.
        * DNS에서 특정 FQDN에 대한 설정을 NS 레코드로 설정하면, NS 레코드의 값에 있는 네임 서버로 재질의한다.
        * DNS와 같은 도메인으로 GSLB를 운영하면서 계층적으로 GSLB를 이용한 FQDN을 관리할 때 사용한다. 즉, 하위 계층에 대해서도 일괄적으로 동일한 GSLB에 위임한다.
        * 아래 예시를 보면 다음과 같은 순서로 DNS를 찾는다.
          * LDNS는 일단 도메인 이름을 기준으로 DNS 서버에 질의하여 NS 레코드를 확인한다.
          * NS으로부터 얻은 도메인 이름은 NS 값에 명시된 도메인 서버가 관리하므로, 도메인 이름에 대한 질의를 GSLB 서버에 보낸다.
          * GSLB에서 최종적으로 IP를 응답한다.

        <figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2F6eZSNdalKcLSpkpcSi1l%2Fimage.png?alt=media&#x26;token=2801b964-5e27-4e91-8218-32b7c2d9393c" alt=""><figcaption></figcaption></figure>

### 분산 방식

* GSLB를 이용해 서비스를 분산하는 목적은 다음과 같다.
  * 서비스 제공의 가능 여부를 체크해 트래픽 분산
  * 지리적으로 멀리 떨어진 다른 데이터 센터에 트래픽 분산
  * 지역적으로 가까운 서비스에 접속해 더 빠른 서비스 제공이 가능하도록 분산
* 서비스 응답/지연 시간(RTT/latency) 기준 또는 IP의 지리 정보를 이용해 분산할 수 있다.
