DNS : 인터넷의 디렉터리 서비스
사람을 주민등록 번호로 식별할 수 있는 것과 마찬가지로, 인터넷 호스트는 Host Name 으로 식별할 수 있다. www.facebook.com 과 같은 호스트 네임은 기억하기 쉬워 사용자에게 편리하다. 하지만 호스트 네임을 통해 곧바로 IP주소를 얻을 수 없다. IP주소를 얻으려면 DNS 서버에서 해당 호스트 네임을 조회하여 주소를 찾아와야 한다.
DNS 라는 용어의 이해
DNS 는 다음과 같이 두가지 의미로 이해할 수 있다.
1. DNS 서버들의 계층구조로 구현된 분산 데이터베이스
2. 호스트가 분산 데이터베이스로 질의하도록 허락하는 어플리케이션 계층 프로토콜
DNS서버는 주로 BIND (Berkely Internet Name Domain) 소프트웨어를 수행하는 유닉스 컴퓨터이다. DNS 프로토콜은 UDP상에서 수행되고 포트번호 53을 사용한다.
DNS가 UDP를 사용하는 이유는, DNS가 전달하는 메시지의 사이즈가 매우 작아 요청이 안정적으로 수행되지 않았을 경우 재요청하는 비용이 작기 때문이다. 전화를 걸기 위해 전화번호를 찾는 과정인 셈이므로, 안정성 보다는 속도를 택한 것이다.
DNS의 역할
* 다른 어플리케이션 프로토콜들이 사용자가 제공한 호스트 네임을 IP주소로 변환하기 위해 주로 사용된다.
* Host Aliasing : 복잡한 호스트 네임을 가진 호스트는 하나 이상의 별명을 가질 수 있다. 정식 호스트 네임(Canonical Hostname)이 만약 relay1.west-coast.enterprise.com 이라 치면, enterprise.com 과 같은 별칭을 가질 수 있다. DNS는 호스트의 IP주소 뿐만 아니라, 별칭 호스트네임에 대한 정식 호스트네임을 얻는데도 사용된다.
* Mail Server Aliasing : bob@hotmail.com 과 같은 전자메일 주소의 정식 호스트네임은 relay1.west-coast.hotmail.com 과 같이 복잡한 것일 수 있는데, 별칭을 이용해 정식 네임을 얻을 수 있다.
* Load Distribution (부하 분산) : DNS는 중복 웹 서버 같은 여러 중복 서버 사이에 부하를 분산하기 위해서도 사용된다. DNS 데이터베이스는 인기 있는 호스트네임에 대한 여러개의 IP주소를 갖고 있고, 클라이언트에게 IP주소를 반환할 때 이 주소들을 리스트를 순환하면서 응답을 보낸다.
분산 계층 데이터베이스
단일 DNS 서버에 있는 중앙 집중 데이터베이스는 확장성이 전혀 없다. 서버가 고장나면 전체 인터넷이 작동하지 않을 수 도 있으며, 전 세계의 수 많은 호스트들에서 발생된 요청을 단일 서버가 처리하게 되면 부하가 심할 것이다. 뿐만 아니라 DNS서버로부터 멀리 있는 호스트는 요청과 응답 과정에서 오랜 시간을 기다려야 할 수 도 있다. 그리고 단일화된 서버는 유지 보수가 매우 어려울 것이다.
따라서 확정성 문제를 해결하기 위해 DNS는 많은 서버를 이용하고, 이들을 계층 형태로 구성하여 전 세계에 분산되어 있다. 대체로 Root DNS 서버 -> 최상위 레벨 도메인 네임 (TLD ; Top level domain) DNS 서버 -> 책임 (authoratative) DNS 서버 를 거쳐서 IP주소를 찾는 방식으로 설계되어 있다.
* 루트 DNS 서버 : 인터넷에는 400개 이상의 루트 DNS서버가 있는데, 이 서버들은 13개의 다른 기관에서 관리된다.
* TLD 서버 : com, org, net, edu 와 같은 상위 레벨 도메인과, kr, uk, fr, ca, jp 같은 모든 국가의 상위 레벨 도메인에 대한 TLD 서버가 있다. TLD 서버들은 책임 DNS 서버들에 대한 IP주소를 제공한다.
* 책임 DNS 서버 (학교나 회사같은 기관에 존재하는 서버) : 웹 서버나 메일 서버를 가진 모든 기관은 호스트네임을 IP주소로 매칭하는 공개적인 DNS레코드를 제공해야 한다. 기관의 책임 DNS서버는 이 DNS레코드를 갖고 있다.
* 로컬 DNS 서버 : 서버들의 계층구조에 엄격하게 속하지는 않는다. 로컬 DNS서버는 프록시로서 동작하여 클라이언트의 요청을 처리할 수 있는지 확인하고, 만약 캐싱되어있지 않은 호스트네임이 요청되었으면 이를 DNS서버 계층으로 전달한다.
DNS 질의 사슬 : 반복적 질의와 재귀적 질의
호스트가 호스트네임을 브라우저에 쳐서 요청하면 로컬 DNS서버를 먼저 확인한다. 만약 로컬에 존재하지 않는다면 반복적으로 Root, TLD, Authorative 서버를 왔다 갔다 하면서 필요한 IP 주소를 찾는다.
재귀적 질의는 요청을 받은 DNS 서버가 다시 다른 계층의 서버로 질의를 떠넘기도록 한다.
DNS 레코드와 메시지
DNS 분산 데이터베이스를 구현한 DNS 서버들은 호스트 네임을 IP주소로 매핑하기 위한 자원 레코드 (Resource record : RR) 을 저장한다. 각 DNS는 하나 이상의 자원 레코드를 가진 메시지로 응답한다.
자원 레코드는 다음과 같은 필드를 포함하는 4개의 Tuple 로 되어있다.
(Name, Value, Type, TTL)
* TTL : Time To Live. 자원 레코드의 생존 기간이다. 이 시간이 지나면 자원이 캐시에서 제거된다.
Name 과 Value 필드는 Type 에 의해 결정된다.
* Type = A : Name = 호스트네임, Value = 호스트네임에 대한 IP주소. 예를 들어 (relay1.bar.foo.com, 145.234.12.12, A) 는 Type A 레코드이다.
* Type = NS : Name = 도메인 (ex. foo.com), Value = 도메인 내부의 호스트에 대한 IP주소를 얻을 수 있는 방법을 아는 책임 DNS 서버의 호스트네임. 예를 들어 (foo.com, dns.foo.com, NS) 는 Type NS 레코드이다.
* Type = CNAME : Name = 호스트 별칭, Value = 별칭에 대한 정식 호스트네임. 예를 들어 (foo.com, relay1.bar.foo.com, CNAME) 은 CNAME 레코드이다.
* Type = MX : Name = 메일 서버의 별칭, Value = 메일 서버의 정식 호스트네임. 예를 들어 (foo.com, mail.bar.foo.com, MX) 는 MX 레코드이다. 메일 서버의 정식 이름을 얻기 위해 DNS클라이언트는 MX 레코드에 대한 질의를 한다.
책임 DNS서버는 호스트네임에 대한 Type A 레코드를 갖고 있다 (최종적인 IP주소를 제공해주는 곳이므로). 책임 서버가 아니라면, 그 서버는 호스트 네임을 포함하는 도메인에 대한 Type NS 레코드를 포함할 것이다 (최종적인 주소가 아니라, '여기로 가라' 식의 dns.~ 과 같은 주소를 주는 것).
* 참고 : 컴퓨터 네트워킹 : 하향식 접근 7판, 한양대학교 이석복 교수님 KOCW 강의
'Computer Network' 카테고리의 다른 글
| [Lecture 5] RDT : Reliable Data Transfer (1) | 2020.07.02 |
|---|---|
| CS144 : Lab 프로젝트 (Github Repository) (0) | 2020.07.01 |
| [Lecture 4-2] Transport Layer (1) : Overview & UDP (0) | 2020.06.29 |
| [Lecture 4-1] Application Layer 마무리 : Mail Server (0) | 2020.06.27 |
| [Lecture 1] Application Layer (1) : HTTP (6) | 2020.06.25 |