본문 바로가기

네트워크/chapter 2. 애플리케이션 계층

2.4 DNS - 인터넷의 디렉터리 서비스

[들어가기 전]

DNS : 5계층 서비스


2.4.0 개요

호스트를 구분짓는 하나의 식별자 : 호스트 네임

하지만. 호스트 네임을 라우터가 처리하는 것은 어렵다. 그래서, IP주소로도 식별된다.

 

즉, 호스트는

1. 호스트 네임

2. IP주소

로 식별될 수 있다


2.4.1 DNS가 제공하는 서비스

사람에게는 호스트 네임이 편하지만, 라우터에게는 IP주소로 호스트를 식별하는 것이 편하다(당연하다)
즉, 호스트 네임을 IP주소로 바꿔주어야 하는데, 이것이 인터넷 DNS(domain name system)의 주 임무이다.

 

DNS는,

1. DNS서버들의 계층구조로 구현된 분산 데이터베이스이고,

2. 호스트가 분산 데이터베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜 이다.

 

DNS 프로토콜은 UDP상에서 수행되고, 포트번호 53번을 이용한다.

 

DNS는, 다른 애플리케이션 프로토콜들이 HTTP 등 사용자가 제공한 호스트 네임을, IP주소로 바꾸는데 사용된다.

그 예시로,  www.someschool.edu/index.html으로 요청을 보낼 때의 동작 상황을 살펴보자.

1. 사용자 컴퓨터가 자신의 컴퓨터 내의 DNS 애플리케이션 클라이언트 측을 수행한다.

2. 브라우저가 URL로부터 호스트 네임 www.someschool.edu 을 추출하고, DNS 애플리케이션 클라이언트측에 해당 호스트 네임을 넘긴다

3. DNS 클라이언트는 DNS 서버로 호스트 네임을 포함하는 질의를 보낸다

4. DNS 클라이언트는 DNS 서버로부터 IP주소를 응답받는다

5. 브라우저가 DNS로부터 IP주소를 받으면, 브라우저는 그 IP주소와 그 주소의 80번 포트에 위치하는 HTTP서버 프로세스로 TCP연결을 초기화한다.

 

DNS의 추가 서비스

1. 호스트 엘리어싱

- 복잡한 호스트 네임을 가진 호스트는, 하나 이상의 별명을 가진다. 예를 들면, 정식 호스트 네임이 relay1.west-coast.enterprise.com 이면, 별칭 호스트 네임은 enterprise.com, www.enterprise.com  2개를 가질 수 있다.

- 이런 상황에서 DNS는, IP주소 뿐만 아니라, 별칭 호스트 네임에 대한 정식 호스트 네임을 얻기 위해 사용된다.

 

2. 메일 서버 엘리어싱

- 별칭 호스트 네임에 대한 정식 호스트 네임을 얻기 위해, 메일 애플리케이션에 의해 수행되는 경우를 말한다

 

3. 부하 분산

- 인기있는 사이트(예 - cnn.com)는 여러 서버에 중복되어 있는 경우가 있다. 즉, 하나의 호스트 네임이 여러 IP 주소를 갖게 된다. DNS 데이터베이스는 이 IP 주소 집합을 가지고 있다.

- 따라서, 클라이언트가 호스트 네임으로 DNS 질의를 수행했을 때, IP 주소 집합 전체를 응답해주는데, 이때 각 응답에서의 주소는 순환식으로 보낸다.

- 따라서, 여러 중복 서버들 사이에서 트래픽을 분산하는 효과를 낸다.

 


2.4.2 DNS 동작 원리 개요

앞으로 살펴볼 DNS 기능은 "호스트 네임을 IP 주소로 변환하는 것"에 초점을 맞춘다는 점을 서두에 언급한다.

 

DNS는, 애플리케이션 관점에서, 호스트 네임을 전달하면 IP 주소를 반환해주는 "블랙박스" 같은 존재이다. 하지만 내부는 사실, 복잡하다.

 

먼저, 단일 DNS 서버를 상상해보자. 클라이언트의 모든 질의는 단일 DNS 서버로 오고, DNS 서버는 직접 클라이언트에게 응답한다. 이럴 경우, 당연히 서버가 고장나면 전체 인터넷이 마비되고, 트래팩이 넘치고, 클라이언트와 서버간의 거리가 멀어지는 경우가 생기고, 유지 관리가 힘들어지게 된다.

따라서, 분산 DNS 서버를 구축해야 한다.


분산 계층 데이터베이스

대체로, 아래 그림과 같이 DNS 서버의 유형은 3가지로 쪼개어진다.

루트 DNS 서버, 최상위 레벨 도메인 DNS 서버, 책임 DNS 서버이다.

 

1. 루트 DNS 서버

대부분 북미 지역에 위치

13개의 다른 기관에서 관리됨

루트 DNS 서버라고 검색해보면, 딱 13개가 나온다. 

TLD DNS 서버에 대한 IP 주소를 제공한다

루트 DNS 서버 목록

 

2. 최상위 레벨 도메인 (TLD) 서버

com,org,net,edu 와 같은 상웨 레벨 도메인과, kr,uk,fk 와 같은 모든 국가의 상위 레벨 도메인에 대한 TLD 서버가 있다.

책임 DNS 서버에 대한 IP 주소를 제공한다

 

3. 책임 DNS 서버

인터넷으로 접근하기 쉬운 호스트(www.naver.com 등)를 가진 모든 기관은, 호스트 네임을 IP 주소로 매핑하는 공개적인 DNS 레코드를 제공해야 한다.

호스트 네임에 대한 IP 주소를 제공한다.

 

4. 로컬 DNS 서버

서버들의 계층 구조에 엄격하게 속하지는 않지만, DNS 구조의 중심에 있다.

대학이나 주거지역 ISP와 같은 ISP들은, 로컬 DNS 서버로부터 IP주소를 호스트에게 제공한다.

대체로, 로컬 DNS 서버는 호스트와 "가까이"에 있다.

 

*참고로, 맥북 기준 [시스템 환경설정->네트워크->DNS] 를 들어가보면, 로컬 DNS의 IP 주소가 결정되어 있는 것을 알 수 있다. 이 로컬 DNS 서버를 바꿀 수도 있다!!

 

DNS 클라이언트가 DNS 질의를 보내는, 첫번째 DNS 서버이다.

그림에서 DNS 서버에 질의가 수행되는 모습을 볼 수 있다. 이때, TLD 서버와 책임 서버 사이에 중간 서버가 있는 경우가 일반적이기 때문에, 그림으로 추가해두었다.

그림에서, DNS 질의의 특징인, 재귀적 질의 / 반복적 질의 가 이루어지는 것을 볼 수 있다.

1. 재귀적 질의 

요청 호스트의 DNS 질의가, 로컬 DNS에게 질의되고, 로컬 DNS가 또 DNS 질의를 수행하므로, 재귀적 질의이다.

2. 반복적 질의

로컬 DNS 서버는 "루트, TLD, 중간, 책임 DNS 서버"로 질의를 전달하고 응답받는 행위를 반복적으로 수행한다. 따라서, 반복적 질의를 수행하게 된다.

 

 


DNS 캐싱

DNS는 중요한 특징인, 캐싱이 있다.

지연 성능 향상과, 네트워크의 DNS 메세지 수를 줄이는 역할을 하게 된다.

 

DNS 캐싱이란. "반복적 질의 사슬에서, 로컬 DNS 서버는 질의에 대한 응답을 받게 되는데, 응답을 받을 때마다 응답에 포함된 정보를 저장할 수 있다."는 것이다

 

그래서, 만약 호스트 네임과 그에 대한 IP 주소의 쌍이 로컬 DNS에 저장되어 있다면, 다른 요청 호스트가 해당 호스트 네임을 요청했을때 IP 주소를 제공할 수 있게 되는 것이다. DNS 서버는 어떤 기간(흔히 2일)이 지나면, 저장된 정보를 제거한다.

 

로컬 DNS 서버는 호스트 네임의 IP 주소를 캐싱할 수도 있지만, TLD 서버의 IP 주소를 저장할 수도 있다. 이런 경우, 로컬 DNS 서버가 질의 사실에서 루트 DNS 서버를 우회할 수 있게 된다.


2.4.3 DNS 레코드와 메세지

DNS 서버들은, 호스트 네임을 IP 주소로 매핑하기 위한 자원 레코드(resource record, RR)를 저장한다.

DNS 서버들은, 하나 이상의 자원 레코드를 가진 메세지로 응답한다.

 

자원 레코드 구성

(Name, Value, Type, TTL) 

- TTL : 자원 레코드의 생존 기간(자원이 캐시에서 제거되는 시간을 결정).

- Name, Value는, Type에 따라 의미가 달라진다

 

1. Type=A

Name : 호스트 네임

Value : 호스트 네임에 대한 IP 주소

예시) (relay1.bar.foo.com, 145.37.93.126,A)

참고로, 여기서 호스트 네임은, 루트 DNS 서버 한개에 대한 이름이여도 되고, 책임 DNS 서버 한개에 대한 이름이여도 되고, 일반적으로 생각하듯 www.naver.com 과 같이 우리가 접속하려는 웹 서버의 호스트 네임이여도 된다.

 

2. Type=NS

Name : 도메인

Value : 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는, 책임 DNS 서버의 호스트 네임

예시) (foo.com, dns.foo.com, NS)

 

3. Type=CNAME

Name : 별칭 호스트 네임

Value : 정식 호스트 네임

예시) (foo.com, 145.37.93.126, CNAME)

 

4. Type=MX

Name : 별칭 호스트 네임

Value : 별칭 호스트 네임을 갖는 메일 서버의, 정식 호스트 네임

예시) (foo.com, mail.bar.foo.com, MX)


퀴즈)

Q : 한 DNS 서버가 책임서버라면, 어떤 타입의 레코드를 가지고 있을 것인가?

A : Type=A. 호스트 네임에 대한 IP 주소를 가지고 있어야 하므로

 

Q : 한 DNS 서버가 책임서버가 아니더라도, Type=A 레코드를 가지고 있을 수 있을까?

A : 네. DNS 캐싱을 통해, 로컬 DNS 서버가 호스트 네임에 대한 IP 주소를 가지고 있을 수 있다. 

 

Q : 한 DNS 서버가 책임서버가 아니라면, 어떤 타입의 레코드를 가지고 있을 것인가?

A : Type=NS, Type=A. 책임 서버의 호스트 네임을 알아야 하고, 로컬 DNS가 그 다음 반복적 질의를 해야할 DNS 서버에 대한 IP 주소를 가지고 있어야 하기 때문이다.

 

예를 들어, 특정 호스트에 대한 책임 서버가 아닌 TLD 서버를 가정하자.

해당 서버는 특정 호스트를 포함하는 도메인에 대한 책임 서버에 대한 호스트 네임을 포함한다.

또한, TLD 서버는 로컬 DNS 서버의 반복적 질의를 위해 다음 서버의 IP 주소를 가지고 있어야 한다.


DNS 데이터베이스에 레코드 삽입

우리가 등록하기 원하는 도메인 네임(networkutopia.com)을 어떻게 등록할 것인가?

 

1. 등록기관에, 주책임 DNS 서버와 부책임 DNS 서버의 이름&IP 주소를 제공하면 된다.

2. 등록기관은, 해당 책임 서버들에 대해 각각 Type=NS, Type=A 레코드를 TLD 서버에 등록하게 된다.

 

예를 들어, 책임 서버의 호스트 네임과 IP 주소가 다음과 같다고 하자.

호스트 네임 : dns1.networkutopia.com

IP 주소 : 212.212.212.1

 

그러면, 등록기관은

Type=NS 레코드 :

(networkutopia.com, dns1.networkutopia.com, NS)

= (등록하기 원하는 도메인 네임, 등록하기 원하는 도메인 네임의 책임 서버의 호스트 네임)

 

Type=A 레코드 :

(dns1.networkutopia.com, 212.212.212.1, A)

= (책임 서버의 호스트 네임, 책임 서버의 IP 주소)

 

를 TLD 서버에 등록(삽입)하게 된다.


이제, 실질적으로 어떤 유저가 우리가 등록한 도메인으로 접속을 원하는 경우를 생각해보자.

 

1. 호주의 앨리스가 networkutopia.com을 입력한다.

2. 로컬 DNS 서버는 루트 DNS 서버에 질의를 하여, com에 대한 정보를 가진 TLD 서버의 IP 주소를 얻는다

3. 로컬 DNS 서버는 TLD DNS 서버에 질의를 하여, 책임 DNS 서버의 호스트 네임, IP 주소를 얻는다 (TLD 서버에는, 등록기관이 등록한 NS, A 타입 레코드가 있기 때문에 책임 DNS 서버의 호스트 네임, IP 주소를 얻을 수 있다)

4. 로컬 DNS 서버는 책임 DNS 서버에 질의하여, 호스트 네임(networkutopia.com)의 IP 주소를 얻는다.

5. 로컬 DNS 서버는 호스트 네임의 IP 주소(A 타입 레코드)를 앨리스 호스트에게 전달한다.

 

6. 이제, 앨리스의 브라우저는 해당 IP주소로 TCP 연결을 맺고, 그 연결로 HTTP 요청을 보낸다!!!

 

이렇게, 웹서핑의 과정은 상당히 복잡한 DNS 애플리케이션의 동작이 포함되어 있다.

즉, DNS가 제공하는 서비스란, "재귀적, 반복적 DNS 질의를 통해, 우리가 원하는 호스트의 IP 주소를 얻게 되는 것"이다!!!