Update 2024-02-22_[7장] DNS.md

docs/playhuck/2024-02-22_[7장] DNS.md

@@ -1,15 +1,248 @@
+<img src="https://github.com/monthly-cs/2024-01-network/assets/105256335/1c32c3f1-c04b-4151-9a5f-3538a1e4a30b">
+
+### 7.2 DNS
+
 네트워크 프로토콜은 크게 두 가지이다.
 
-- 실제로 데이터를 실어나르는 데이터 프로토콜
-- 데이터 프로토콜 제어를 도와주는 컨트롤 프로토콜
+1. 실제로 데이터를 실어나르는 데이터 프로토콜
+2. 데이터 프로토콜 제어를 도와주는 컨트롤 프로토콜
 
 TCP/IP 프로토콜 체계를 유지하기 위한 주요 컨트롤러 프로토콜은 ARP / ICMP / DNS가 있다.
 
 이 중 DNS(Domain Name System)는 도메인 주소를 IP 주소로 변환하는 역할을 한다.
 
-1. **DNS 소개**
+- **7.2.1 DNS 소개**
 
 
     숫자로 구성된 IP 보다 문자열인 도메인 주소가 더 기억하기 쉽다.
 
     서비스를 도메인 주소로 사용하더라도 실제 패킷을 만들어 통신하기 위해서는 3계층 IP 주소를 알아야 하고, 이를 위해 문자열로 된 도메인 주소를 실제 통신에 필요한 IP 주소로 변환하는 DNS 작업이 필요하다.
+
+    예를들면, naver.com으로 접속을 클라이언트가 원한다고 치면
+
+    1. Client가 DNS 서버로 www.naver.com으로 질의 전송
+    2. DNS 서버가 Client에게 naver.com의 주소가 202.179.177.21이라고 응답
+    3. Client는 202.179.177.21라는 IP 주소를 통해 naver.com으로 접속
+
+    이라는 흐름으로 DNS 서버를 통해 실제 IP 주소에 접근할 수 있게 된다.
+
+- **7.2.2 DNS 구조와 명명 규칙**
+
+
+    일반적으로 도메인은 계층 구조(Layerd Architecture)다.
+
+
+역트리 구조로 최상위 루트부터
+
+1. Top-Level 도메인 / com
+2. Second-Level 도메인 / naver
+3. Third-Level 도메인 / www
+
+도메인은 최대 128 계층으로 구성할 수 있다. 계층별 길이는 최대 63바이트다.
+
+**7.2.2.2 Top-Level Domain(TLD)**
+
+최상위 도메인인 TLD는 IANA(Internet Assigned Numbers Authority)에서 구분한 6가지 유형으로 구분한다.
+
+- Generic (gTLD)
+
+    ⇒ 특별한 제한 없이 사용되는 최상위 도메인, 세 글자 이상으로 구성
+
+    - com / 일반 기업체
+    - edu / 4년제 이상 교육기관
+    - gov / 미국 연방정부기관
+    - int / 국제기구
+    - mil / 미국 연방군사기관
+    - net / 네트워크 관련 기관
+    - org / 비영리기관
+- country-coded (ccTLD)
+
+    ⇒ 국가 최상위 도메인, ISO 3166 표준에 의거한 두 글자 국가 코드 사용 한국의 경우 kr을 사용한다.
+
+- sponsored (sTLD)
+
+    ⇒ 특정 목적을 위한 스폰서를 두고 있는 도메인
+
+    - aero
+    - asia
+    - edu
+    - museum
+- infrastructure
+
+    ⇒ 중요한 인프라 식별자 공간을 지원하기 위한 전용
+
+    - arpa
+- generic-restricted (grTLD)
+
+    ⇒ 특정 기준을 충족하는 사람이나 단체
+
+    - biz
+    - name
+    - pro
+- test (tTLD)
+
+    ⇒ 테스트 혹은 개발 단계의 목적으로 사용
+
+    - test
+    - dev
+
+
+**7.2.3 DNS 동작 방식**
+
+domain을 IP로 변환하려면 DNS 서버에 도메인 쿼리하는 과정을 거쳐야 한다.
+
+하지만, DNS 서버 없이 로컬과 도메인에 IP 주소를 직접 설정해 사용할 수도 있다.
+
+해당 관리 파일을 hosts 파일이라고 한다. hosts 파일에 도메인과 IP 주소를 설정해두면 해당 도메인 리스트는 DNS 캐시에 저장된다.
+
+쿼리를 하면 DNS 서버에 하기 전 항상 DNS 캐시 정보를 먼저 확인한다.
+
+```jsx
+ipconfig /displaydns // window dns 캐시 명령
+```
+
+DNS는 본인이 가진 db에 정보가 없다면, 분산된 다른 DNS의 데이터베이스로부터 질의해 결과를 받을 수 있다.
+
+DNS 서버 관점에서 동작을 살펴보면,
+
+1. zigispace.net이라는 도메인을 Client가 DNS 서버에 쿼리
+2. [zigispace.net](http://zigispace.net)이 로컬 캐시에 저장되있지 않다면, 사용자 호스트에 설정된 DNS에 zigispace.net 쿼리
+3. DNS 서버는 루트 DNS에 다시 쿼리하고 루트 DNS는 .net에 대한 정보를 관리하는 DNS 주소 정보를 DNS 서버에 응답
+4. 응답 받은 DNS 서버는 .net을 관리하는 DNS 서버에 zigispace.net에 대해 쿼리
+5. .net을 관리하는 서버는 다시 zigispace.net을 관리하는 DNS에 쿼리
+6. 최종적으로  zigispace.net에 대한 결과값 반환
+7. 처음 쿼리를 받은 DNS 서버는 이 정보를 Client에 응답
+
+**7.2.4 마스터와 슬레이브**
+
+DNS 서버는 마스터와 슬레이브 서버로 나눌 수 있다.
+
+차이는 도메인에 대한 Zone 파일을 직접 관리하는지 여부다.
+
+마스터 서버는 모든 도메인에 마스터고, 슬레이브는 모두 슬레이브로 설정하는 것이 바람직하다.
+
+<aside>
+💡 액티브-스탠바이와 액티브-액티브
+
+고가용성 기술을 위해 사용하는 구조가 액티브-액티브 / 액티브-스탠바이 이다.
+
+1. 액티브-액티브는 두 개의 노드가 동시에 서비스를 제공하고 한 노드에 문제가 생긴 경우 다른 노드에서 서비스를 제공하는 방식
+2. 액티브-스탠바이는 두 개의 노드 중 액티브만 제공하고 스탠바이는 대기하는 형식이다.
+
+</aside>
+
+**7.2.5 DNS 주요 레코드**
+
+도메인의 주요 레코드는 아래와 같다.
+
+1. A (IPv4 호스트) : 도메인 주소를 IPv4로 매핑
+
+
+    하나의 A 레코드에는 한 개의 도메인 주소와 한 개의 IP 주소가 1:1로 매핑된다. 동일 도메인을 가진 A 레코드 여러 개를 만들어 서로 다른 IP 주소와 매핑할 수 있다.
+
+    반대로, 다수의 도메인에 동일한 IP를 매핑한 A 레코드를 만들 수도 있다.
+
+2. AAAA (IPv6 호스트) : 도메인 주소를 IPv6으로 매핑
+
+
+    A 레코드와 같음
+
+3. CNAME (별칭) : 도메인 주소에 대한 별칭
+
+
+    대표적인 예로, www가 있다.
+
+4. SOA (권한 시작) : 본 영역 데이터에 대한 권한
+
+
+    도메인 영역 선언 시 SOA 레코드는 필수 항목이다. 도메인 관리에 필요한 속성값을 설정한다.
+
+5. NS (도메인의 네임 서버) : 본 영역에 대한 네임 서버
+
+
+    도메인에 대한 권한이 있는 네임 서버 정보를 설정하는 레코드
+
+6. MX (메일 교환기) : 도메인 메일 서버 정보
+7. PTR (포인터) : IP 주소를 도메인에 매핑 (역방향)
+
+
+    A 레코드에 대한 반대로, IP 주소에 대한 질의를 도메인 주소로 응답하기 위한 레코드다.
+
+8. TXT (레코드) : 도메인에 대한 일반 텍스트
+
+
+    도메인에 대한 설명을 달 수 있다. 최대 255자
+
+
+**7.2.6 DNS에서 알아두면 좋은 것들**
+
+1. 도메인 위임
+
+
+    도메인의 모든 영역은 정보 관리를 위한 네임 서버를 지정하지만, 일부 영역에 대해서 관리하도록 위임하기도 한다.
+
+    CDN을 이용하거나 GSLB를 사용하는 것이 그 사례다.
+
+
+1. TTL
+
+
+    도메인의 TTL은 DNS 질의 후 응답받은 결과값을 캐시에서 유지하는 시간을 의미한다.
+
+    TTL 값을 늘려 캐시를 많이 쓰면, DNS 재귀적 쿼리로 응답시간을 줄일 수 있고 네트워크 응답 시간이 줄어들지만, DNS 관련 도메인 정보가 변경됐을 때 TTL 값이 크면 DNS 정보 갱신이 그만큼 지연되는 단점이 있다.
+
+    반대로, TTL이 너무 작으면 DNS 정보 갱신이 빨라져 쿼리량이 늘어나 DNS 서버 부하가 증가한다.
+
+    Window Default TTL = 3,600 (1시간)
+
+    Linux Default TTL = 10,800 (3시간)
+
+
+1. 화이트 도메인
+
+
+    블랙리스트의 반대말
+
+2. 한글 도메인
+
+
+    “http://한국인터넷진흥원.한국” 처럼 한글로도 주소를 만들 수 있다.
+
+    DNS에서 해당 한글을 “퓨니코드”로 변경하고 DNS를 생성해야 한다.
+
+
+---
+
+### 7.3 GSLB
+
+DNS에서 동일한 레코드 이름으로 서로 다른 IP 주소를 동시에 설정할 수 있다.
+
+이렇게 설정하면 응답 IP 주소 따라 로드밸런싱할 수 있다.
+
+하지만, DNS 로드밸런싱은 한계가 존재한다.
+
+DNS는 설정상 서비스 상태의 정상 여부(Health Check)를 확인하지 않고 도메인에 대한 질의에 대해 설정된 값을 무조건 응답한다.
+
+GSLB는 도메인을 이용한 로드 밸런싱을 도와준다.
+
+GSLB는 Health Check를 지원하며 정상인 레코드에 한해 사용하게 도와준다.
+
+- **7.3.1 GSLB 동작 방식**
+
+
+    1. Client가 webSite에 접속하기 위해 DNS에 질의
+    2. LDNS는 webSite를 관리하는 NS 서버를 찾기 위해, root부터 순차 질의
+    3. webSite를 관리하는 NS 서버로 질의
+    4. DNS 서버는 GSLB로 wetSite에 대해 위임 했기 때문에, GSLB 서버가 NS 서버라고 LDNS에 응답
+    5. LDNS는 다시 GSLB로 webSite에 질의
+    6. GLSB는 webSite에 대한 IP 주소값 중 현재 설정된 분산 방식에 따라 특정 센터의 IP 주소 값을 DNS에 응답, 이 때에 Health Check를 거쳐 정상인 값만 응답
+    7. GLSB에서 결과 값을 응답받은 LDNS는 사용자에게 webSite가 1.1.1.1로 서비스하고 있다고 최종 응답
+
+- **7.3.2 GLSB 구성 방식**
+    - 도메인 자체를 GSLB로 사용 ⇒ Health Check의 과부하 문제가 발생할 수 있다.
+    - 도메인 내의 특정 레코드만 GSLB를 사용
+
+- **7.3.3 GSLB 분산 방식**
+    - 서비스 제공의 가능 여부를 체크해 트래픽 분산
+    - 지리적으로 멀리 떨어진 다른 데이터 센터에 트래픽 분산
+    - 지역적으로 가까운 서비스에 접속해 더 빠른 서비스 제공이 가능하도록 분산