[21.10.6] 1 - DNS 대략적인 개념

http://www.yes24.com/Product/Goods/93997435

IT 엔지니어를 위한 네트워크 입문 - YES24

 

해당 서적을 바탕으로 작성하였씁니다. 

 

 

 

 

예전 수업시간 때 DNS 구현을 해봤던 기억이 나는데 원리에 대한 파악이 부족하여 이 글을 작성했다. 

 

DNS란?

인터넷을 사용할 때 우리는 수 많은 사이트에 접속한다. 이러한 사이트를 접속할 때 우리는 202.179.177.21 같은 IP주소를 URL에 치는 것이 아닌 도메인 주소를 사용한다. 만약 긴 IP 주소를 써야한다면 전화번호부 외우듯 IP 주소를 모두 기억해야만 하는 괴로움이 발생되기 때문이다.

 

 

 이를 위해 문자열로 된 도메인 정보를 실제 통신에서 필요한 IP 주소로 변환하는 서버를 DNS(Domain Name Server)라고 하며, 클라가 웹 브라우저를 통해 도메인 주소를 사용하여 서비스를 요청한다면 네트워크 설정에 입력한 DNS(여기서는 8.8.8.8과 8.8.4.4 구글 DNS가 된다.)로 해당 도메인에 대한 IP 주소 질의를 보내고 결과 값으로 요청한 도메인의 서비스 IP 주소를 받게 된다. 

 

위의 설명을 그림으로 간단히 나타내면 다음과 같다. 

 

 

 

 

위와 같은 외부간의 연결뿐만 아니라 내부 망에서 사용하는 서비스 간 연결도 DNS를 사용하곤 한다. 일반적으로 내부간의 연결은 IP로 연결을 구현하지만 어느 한 서비스의 IP 변경이 필요할 경우 여러가지 설정을 변경하거나 프로그램을 재배포 해야한다. 서비스 간 연결에 도메인 주소를 사용한다면 DNS 서버에서 간단한 설정 변경만으로 복잡한 서비스 간 연결을 쉽게 변경할 수 있다. 

 

 

 

DNS의 구조

도메인은 분산형 데이터베이스이기 때문에 계층구조를 띄고 있다. 한 곳에 데이터가 집중되지 않으며 수 많은 인터넷 주소중 원하는 주소를 효율적으로 찾아갈 수 있다. 역 트리구조로 최상위 루트부터 Top-Level 도메인, Second-Level 도메인, Third-Level 도메인과 같이 하위 레벨로 원하는 주소에 대한 DNS 서버를 단계적으로 찾아간다. 

 

예를들어 www.naver.com을 보면 맨 뒤에 생략된 루트 도메인(.), Top-Level Doamin(com), naver, www와 같이 뒤에서 앞으로 해석된다고 볼 수 있다. 

 

 

 

 

루트 도메인은 13개의 서버가 존재한다. 

루트 도메인은 역 계층 트리에서 최상위 영역에 존재하는 도메인 서버이다. DNS 서버는 일단 클라가 요청한 쿼리 도메인에 대한 값을 직접 갖고 있거나 도메인 서버에 있는 캐시에 저장된 데이터 정보로 이용해 응답한다. 하지만 DNS 서버에 해당하는 도메인 정보가 없다면 서버는 루트 도메인을 관리하는 루트 DNS에 쿼리 요청을 하게 된다. 

 

루트 DNS는 전 세계에서 13개가 존재하며 BIND와 같은 DNS 서버를 설치하면 루트 DNS의 IP 주소를 기록한 힌트(Hint) 파일을 가지고 있어서 루트 DNS 관련 정보를 별도로 설정할 필요가 없다.

 

 

전 세계 루트 DNS 서버와 루트 DNS 서버의 아이피, 관리 기관은 다음과 같다.

 

 

호스트 이름	IP 주소	관리 기관
a.root-servers.net	198.41.0.4	VeriSign, Inc.
b.root-servers.net	192.228.79.201	University of Southern California
c.root-servers.net	192.33.4.12	Cogent Communications
d.root-servers.net	192.7.91.13	University of Maryland
e.root-servers.net	192.203.230.10	NASA
f.root-servers.net	192.5.5.241	Internet Systems Consortium, Inc.
g.root-servers.net	192.112.36.4	US Department of Defense(NIC)
h.root-servers.net	198.97.190.53	US Army (Research Lab)
i.root-servers.net	192.36.148.17	Netnod
j.root-servers.net	192.58.128.30	VeriSign, Inc.
k.root-servers.net	193.0.14.129	RIPE NCC
l.root-servers.net	199.7.89.42	ICANN
m.root-servers.net	202.12.27.33	WIDE Project

https://ko.wikipedia.org/wiki/%EC%84%9C%EB%8D%98%EC%BA%98%EB%A6%AC%ED%8F%AC%EB%8B%88%EC%95%84_%EB%8C%80%ED%95%99%EA%B5%90

서던캘리포니아 대학교 - 위키백과, 우리 모두의 백과사전

https://ko.wikipedia.org/wiki/%EB%B2%A0%EB%A6%AC%EC%82%AC%EC%9D%B8

베리사인 - 위키백과, 우리 모두의 백과사전

 

(관리기관을 검색해보니 대학교부터 기업까지 다양한 기관들이 루트 도메인을 운영하더라...)

 

 

 

Top-Level Domain(TLD)는 IANA에서 구분한 6가지의 유형으로 구분할 수 있다. 자세한 내용은 다음의 URL에 있다.

 

 https://www.iana.org/domains/root/db

Root Zone Database

 

 

 

 

 

DNS 동작 방식 

DNS 동작 방식은 클라의 입장과 서버의 입장 2가지로 볼 수 있다. 

 

1. 클라의 입장에서 봤을 때 

도메인을 IP 주소로 변환하려면 DNS 서버에서 도메인 쿼리를 하는 과정을 거처야 한다. 하지만 로컬 내에서 도메인과 IP 주소를 매핑하여 설정해 사용할 수 있다. 이 파일을 hosts 파일이라고 한다. 

 

 

보통 다음 경로에 hosts 파일이 있다. 

C:\Windows\System32\drivers\etc\hosts 

 

 

hosts 파일에 도메인과 IP 주소를 설정해둔다면 해당 도메인은 항상 DNS 캐시에 저장된다. 즉 hosts는 정적 DNS 캐시라고 생각하면 된다. 

 

도메인을 쿼리한다면 DNS 서버에 쿼리를 하기 전에 자신의 로컬에 있는 DNS 캐시 정보를 먼저 확인한다. 동일한 도메인을 매번 질의한다면 서버 입장에서도 부하가 생기며, 클라 입장에서도 대기 시간이 길어지니 캐시를 통해서 성능을 향상시키기 위함이다. 이런 DNS 캐시 정보는 기존 DNS 조회를 통해 확인한 동적 DNS 캐시 + hosts 파일에 저장되어 있는 정적 DNS 캐시가 함께 저장되어 있다. 

 

만약 DNS 캐시 정보에 필요한 도메인 정보가 없다면 DNS 서버로 쿼리를 수행하며, DNS 서버로부터 응답을 받는다면 클라의 DNS 캐시에 저장한다. 쿼리를 한 번 수행한 DNS 정보는 캐시 정보부터 조회하므로 DNS 서버에 별도로 쿼리하지 않고도 캐시 정보를 사용한다. 

 

DNS 캐시를 확인하는 명령어는 ipconfig /displays 명령을 사용하면 된다.

 

dns 캐시 정보가 들어있다. 이러한 캐시 정보를 삭제하려면 ipconfig/flushdns 명령어를 치면 된다.

 

 

 

 

 

2. DNS 서버 입장에서 봤을 때 

반대로 DNS 서버 관점에서 도메인에 대한 결과값을 클라에게 보내주는 과정을 살펴보자. 위에 설명했다시피 전 세계 도메인 정보를 DNS 서버 하나에 저장하면 편하겠지만 과부하나 저장영역의 한계 때문에 현실은 그럴 수 없다. 그래서 분산된 데이터베이스 형태로 서로 도와주도록 설계되었다. 자신이 가진 도메인 정보가 아니라면, 즉 클라가 요청한 도메인이 없다면 다른 DNS로 쿼리를 하여 결과를 받을 수 있다. 

 

DNS 기능을 임의의 서버에 올린다면 DNS 서버는 기본적으로 루트 DNS 정보를 갖고 있다. 이것을 이용하여 클라의 DNS 요청 쿼리가 DNS 서버에 없다면 루트 DNS에 질의를 하며, 루트 DNS는 쿼리한 도메인의 TLD(Top Level-Domain) 값을 확인하여 해당하는 TLD 값을 관리하는 DNS 서버가 어디인지 응답하게 된다.

 

1. 만약 클라가 naver.com 이라는 도메인을 DNS(8.8.8.8) 서버에 쿼리를 했다면 DNS 서버는 루트 DNS에 다시 쿼리를 하며, 루트 DNS는 .com 을 관리하는 DNS 서버가 어디인지 응답한다.

2. 또 다시 8.8.8.8 DNS 서버가 .com을 관리하는 DNS 서버에게 naver.com에 대한 쿼리를 요청한다. 이 요청을 받은 .com을 관리하는 DNS 서버는 naver.com을 관리하는 DNS 서버의 주소로 응답한다.

3. 마지막으로 8.8.8.8 DNS 서버는 최종적으로 naver.com을 관리하는 DNS에 쿼리를 하며 naver.com에 대한 최종 결과 값을 받는다. 

4. 처음 쿼리를 받은 DNS 서버는 이 정보를 자신의 캐시에 저장하고 클라에게 응답한다. 

(8.8.8.8 구글 DNS로 비유를 했지만... 보통 8.8.8.8 구글 DNS는 전 세계의 호스트들이 수 많은 요청으로 인해 DNS 서버 캐시 데이터에 왠만한 도메인은 있을 것이다.)

 

 

상당히 복잡해 보이지만 역 트리 계층에 대한 개념만 잡고 있으면 쉽다고? 느껴질 것이다. 

 

참고로 클라와 같은 호스트가 DNS 서버에 질의했던 방식을 재귀적 쿼리(Recursive Query)라고 하며, DNS 서버가 루트 도메인 서버, TLD, Second Level Domain등을 질의하는 방식을 반복적 쿼리(Iterative Query)라고 한다.

 

 

다음에는 DNS를 구성하는 주요 레코드 종류와 Cent OS 7 bind 패키지를 이용한 DNS 서버를 구축하는 과정등을 작성하겠다.