-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Lim
committed
Feb 15, 2024
1 parent
7c1675b
commit 04e0936
Showing
2 changed files
with
84 additions
and
0 deletions.
There are no files selected for viewing
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 서버는 마스터 서버에 문제가 발생하고 일정 시간이 지나면 슬레이브 서버도 도메인에 대한 질의에 정상적으로 응답할 수 없음 | ||
- 이 시간을 만료시간이라고 함 | ||
- 만료 시간 안에 슬레이브 서버가 마스터 서버에서 존 정보를 받아오지 못하면 슬레이브의 존 정보는 사용할 수 없게 됨 |