Skip to content

Commit

Permalink
2024-02-15
Browse files Browse the repository at this point in the history
  • Loading branch information
Lim committed Feb 15, 2024
1 parent 7c1675b commit 04e0936
Show file tree
Hide file tree
Showing 2 changed files with 84 additions and 0 deletions.
Binary file added docs/sk-lim19f/2024-02-15.JPEG
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
84 changes: 84 additions & 0 deletions docs/sk-lim19f/2024-02-15.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
# 7.2 DNS

- 네트워크 프로토콜은 크게 두 가지로 나눌 수 있음
- 실제로 데이터를 실어나르는 데이터 프로토콜과 이 데이터 프로토콜이 잘 동작하도록 도와주는 컨트롤 프로토콜
- 컨트롤 프로토콜은 통신에 직접 관여하지 않지만 처음 통신 관계를 맺거나 유지하는 데 큰 역할을 함
- TCP/IP 프로토콜 체계를 유지하기 위한 주요 컨트롤 프로토콜에는 ARP, ICMP, DNS가 있음
- 이중 DNS는 도메인 주소를 IP 주소로 변환하는 역할을 함
- MSA(Micro Service Architecture) 기반의 서비스 설계가 많아지면서 다수의 API를 이용하다보니 사용자의 호출뿐만 아니라 서비스 간 API 호출이나 인터페이스가 많아져 DNS의 역할이 더 중요해짐

### 7.2.1 DNS 소개

- 사용자가 웹 브라우저에 naver.com을 입력하면 DNS 서버에 naver.com의 주소가 무엇인지 질의하고 DNS 서버는 naver.com의 IP 주소가 202.179.177.21이라고 사용자에게 알려줌
- 사용자는 DNS로 응답받은 202.179.177.21이라는 주소가 IP 주소를 이용해 실제 naver.com에 접속하게 됨

### 7.2.2 DNS 구조와 명명 규칙

- 도메인은 계층 구조여서 수많은 인터넷 주소 중 원하는 주소를 효율적으로 찾아갈 수 있음
- 역트리 구조로 최상위 루트부터 Top-Level 도메인, Second-Level 도메인, Third-Level 도메인과 같이 하위 레벨로 원하는 주소를 단계적으로 찾아감
- 우리가 도메인 주소를 사용할 때는 각 계층의 경계를 "."으로 표시하고 뒤에서 앞으로 해석함

#### 7.2.2.1 Root Domain

- 도메인을 구성하는 최상위 영역
- 루트 DNS는 전 세계에 13개가 있고 DNS 서버를 설치하면 루트 DNS의 IP 주소를 기록한 힌트 파일을 가지고 있어 루트 DNS 관련 정보를 별도로 설정할 필요가 없음

#### 7.2.2.2 Top-Level Domain(TLD)

- 최상위 도메인인 TLD는 IANA(Internet Assigned Numbers Authority)에서 구분한 6가지 유형으로 구분
- Generic TLD(gTLD)
- gTLD는 특별한 제한없이 일반적으로 사용되는 최상위 도메인이며 세 글자 이상으로 구성
- 초기 7개의 gTLD(.com, .edu, .gov, .int, .mil, .net, .org)로 시작했으며 필요에 의해 새로운 gTLD가 지속적으로 만들어지고 있음
- Country Code TLD(ccTLD)
- ccTLD는 국가 최상위 도메인으로 ISO 3166 표준에 의해 규정된 두 글자의 국가 코드를 사용
- 우리나라는 'kr'을 사용
- Sponsored(sTLD)
- sTLD는 특정 목적을 위한 스폰서를 두고 있는 최상위 도메인
- 스폰서는 특정 민족공동체, 전문가 집단, 지리적 위치 등이 속할 수 있음
- sTLD의 종류에는 '.aero', '.asia', '.edu', '.museum'등이 있음
- Infrastructure
- 운용상 중요한 인프라 식별자 공간을 지원하기 위해 전용으로 사용되는 최상위 도메인
- Infrastructure에 속하는 TLD는 '.arpa'
- Generic-restricted(grTLD)
- grTLD는 특정 기준을 충족하는 사람이나 단체가 사용할 수 있는 최상위 도메인
- grTLD의 종류네는 '.biz', '.name', '.pro'가 있음
- Test(tTLD)
- tTLD는 IDN(Internationalized Domain Names) 개발 프로세스에서 테스트 목적으로 사용하는 최상위 도메인
- tTLD의 종류에는 '.test'가 있음

### 7.2.3 DNS 동작 방식

- 도메인을 IP 주소로 변환하려면 DNS 서버에 도메인 쿼리하는 과정을 거쳐야 함
- 하지만 DNS 서버 없이 로컬에 도메인과 IP 주소를 직접 설정해 사용할 수도 있음
- 로컬에서 도메인과 IP 주소를 관리하는 파일을 hosts 파일이라고 함
- hosts 파일에 도메인과 IP 주소를 설정해두면 해당 도메인 리스트는 항상 DNS 캐시에 저장됨
- 도메인을 쿼리하면 DNS 서버에 쿼리를 하기 전 로컬에 있는 DNS 캐시 정보를 먼저 확인 (캐시를 통한 성능 향상)
- 이런 DNS 캐시 정보에는 기존 DNS 조회를 통해 확인한 동적 DNS 캐시와 함께 hosts 파일에 저장되어 있는 정적 DNS 캐시가 함께 저장되어 있음
- DNS 캐시 정보에 필요한 도메인 정보가 없으면 DNS 서버로 쿼리를 수행하고 DNS 서버로부터 응답을 받으면 그 결과를 캐시에 먼저 저장
- 전에 쿼리를 한 번 수행한 DNS 정보는 캐시부터 조회하므로 DNS 서버에 별도로 쿼리하지 않고 캐시 정보를 사용
- 전 세계 도메인 정보를 DNS 서버 하나에 저장할 수는 없음
- 데이터 자체도 방대하지만 인터넷에 엄청나게 많은 사용자가 등록하고 삭제하는 도메인 리스트를 실시간으로 업데이트할 수 없기 때문
- 그래서 DNS는 분산된 데이터베이스로 서로 도와주도록 설계되었는데 자신이 가진 도메인 정보가 아니면 다른 DNS에 질의해 결과를 받을 수 있음
- DNS 기능을 서버에 올리면 DNS 서버는 기본적으로 루트 DNS 관련 정보를 가지고 있음
- 클라이언트의 쿼리가 자신에게 없는 정보라면 루트 DNS에 쿼리하고 루트 DNS에서는 쿼리한 도메인의 TLD 값을 확인해 해당 TLD 값을 관리하는 DNS가 어디인지 응답
- 클라이언트에서 처음 질의를 받은 DNS가 중심이 되어 책임지고 루트 DNS부터 상위 DNS에 차근차근 쿼리를 보내 결과값을 알아낸 후 최종 결과값만 클라이언트에 응답
- 클라이언트는 한 번의 쿼리를 보내지만 이 요청을 받은 DNS 서버는 여러 단계로 쿼리를 상위 DNS 서버에 보내 정보를 획득
- 호스트가 DNS 서버에 질의했던 방식을 재귀적 쿼리(Recursive Query)라고 하고 DNS 서버가 루트 NS와 TLS NS, zigspace NS에 질의한 방식을 반복적 쿼리(Iterative Query)라고 함

> 재귀적 쿼리와 반복적 쿼리
- 재귀적 쿼리는 쿼리를 보낸 클라이언트에 서버가 최종 결괏갑을 반환하는 서버 중심 쿼리
- 반복적 쿼리는 최종값을 받을 때까지 클라이언트에서 쿼리를 계속 진행하는 방식

### 7.2.4 마스터와 슬레이브

- DNS 서버는 마스터 서버와 슬레이브 서버로 나눌 수 있음
- 마스터 서버가 우선순위가 더 높지 않고 두 서버 모두 도메인 쿼리에 응답
- 마스터와 슬레이브는 도메인에 대한 존 파일을 직접 관리하는지 여부로 구분
- 마스터 서버는 존 파일을 직접 생성해 도메인 관련 정보를 관리하고 슬레이브 서버는 마스터에 만들어진 존 파일을 복제
- 이 과정을 '영역 전송(Zone Transfer)'이라고 함
- DNS 마스터 서버와 슬레이브 서버는 이중화에서 일반적으로 사용하는 액티브-스탠바이나 액티브-액티브 형태로 구성하지 않음
- 보통 이중화 방식은 액티브 장비의 문제가 발생하더라도 또 다른 액티브나 스탠바이 장비가 그대로 서비스
- 반면 DNS 서버는 마스터 서버에 문제가 발생하고 일정 시간이 지나면 슬레이브 서버도 도메인에 대한 질의에 정상적으로 응답할 수 없음
- 이 시간을 만료시간이라고 함
- 만료 시간 안에 슬레이브 서버가 마스터 서버에서 존 정보를 받아오지 못하면 슬레이브의 존 정보는 사용할 수 없게 됨

0 comments on commit 04e0936

Please sign in to comment.