[네트워크] DNS란?

DNS

DNS는 Domain Name System의 약어다.

 

인터넷 호스트들은 www.naver.com 이나 www.conx.co.kr 과 같이 모두 호스트 이름을 통해 식별될 수 있다.

하지만 호스트 이름은 길며, 가변적이기 때문에 실제로는 IP주소를 사용해 호스트를 식별한다. 이에따라 IP주소는 호스트이름과 다르게 왼쪽에서부터 조사하여 호스트가 인터넷에 어디에 위치하는지 역시 더 알기 쉬워진다.

 

따라서 우리가 네이버에 접속하려면 네이버 호스트이름이 아닌, IP주소를 알아서 그 IP주소로 요청을 보내야한다. 그러나 사용자가 매번 IP주소를 아는 것은 어렵기 때문에, 더 기억하기 쉬운 호스트 이름을 주면 실제로 요청을 보낼 IP주소를 알려주는 시스템이 필요한데, 이를 DNS라고 한다.

 

DNS는 다음과 같은 기능이 있다.

 

1. 호스트 이름에 대한 IP주소 반환

2-1. 호스트 이름이 복잡한 경우 이를 간소화시킬 수 있다. 호스트가 baseball.sports.naversports.com 이라고할 때, naversports.com과 같은 더 짧은 별칭을 사용할 수 있다. 전자를 정식 호스트 이름(canonial hostname)이라고하며, 이를 호스트 에일리어싱(host aliasing)이라고 칭한다.

2-2. 전자메일의 경우에도 호스트 에일리어싱을 진행할 수 있다. seoul-mapo.korea.gomail.com의 경우 gomail.com으로도 호스트 에일리어싱을 진행할 수 있다. 전자메일에서 진행되므로 전자메일 에일리어싱(mail server aliasing)이라고 칭한다.

2. DNS는 특정한 호스트 이름에 대해서 "이 호스트의 진짜 이름을 알려줘"라는 질의에 응답할 수 있다.

3. 분산 서버를 이용하고 있는 경우 같은 호스트 이름에 대해서 여러 개의 IP주소를 돌아가며 반환한다. 따라서 부하 분산(load distribution)에 대한 효과를 얻을 수 있다.

 

DNS는 UDP를 사용한다.

---

DNS의 동작

DNS 서버는 단일서버가 아니라 계층구조를 이루고 있다.

 

루트 DNS 서버

DNS 서버에 질의를 하려면 가장 먼저 거친다. 전세계 여러 개의 루트 DNS 서버가 존재한다.

 

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

루트 DNS 서버는 호스트의 .com, .net, .org 등 최상위 도메인을 보고 이 상위 도메인을 관리하는 DNS 서버 측으로 질의를 넘긴다.

 

책임 DNS 서버

호스트 이름을 IP 주소로 매핑시킨다. 최종적으로 IP주소를 얻기 위해 도달해야한다.

 

로컬 DNS 서버

모든 호스트들이 직접 DNS 서버로 질의를 보내는게 아니라, ISP마다 설치된 로컬DNS 서버를 거치게된다. 프록시서버와 같이 중간에 요청을 가로채서 동작한다. 캐싱 기능과 더불어서 DNS 질의 성능향상에 기여한다.

---

DNS는 다음과 같이 동작한다.

0. 홍익대학교 컴퓨터공학과 모 강의실에 설치된 PC를 통해서 sports.naver.com에 접근한다. PC 호스트 이름은 cs.hongik.ac.kr이며, 로컬DNS 주소는 dns.hongik.ac.kr다.

1. 로컬 DNS 서버가 요청을 받은 후에 DNS서버로 sports.naver.com에 대한 호스트 IP주소를 얻기 위한 질의를 시작한다.

2. 로컬 DNS 서버는 루트 DNS 서버에 제일먼저 요청을 보낸다.

3. 루트 DNS 서버는 sports.naver.com의 .com을 보고 .com에 대한 TLD 서버의 IP주소를 응답한다.

4. 로컬 DNS 서버는 이 IP주소로 DNS 질의를 보낸다.

5. TLD DNS 서버는 호스트이름 sports.naver를 보고 네이버의 책임 DNS 서버 dns.naver.com의 IP주소를 반환한다.

6. 로컬 DNS 서버는 네이버의 책임 DNS 서버로 요청을 보낸다.

7. 네이버의 책임 DNS 서버는 이를 확인하고 제대로된 IP주소를 응답한다.

8. 로컬 DNS 서버가 다시 호스트에게 이를 반환한다.

 

만약 sports.naver.com이 아니라 conx.co.kr이라면 루트 → kr → co → conx의 과정을 거친다.

 

일반적인 DNS 질의는 위의 그림에서 오른쪽 형태를 띈다.

위의 예시에서 cs.hongik.ac.kr 호스트는 로컬 DNS 서버 dns.hongik.ac.kr이 자신을 대신해 필요한 정보를 얻어오므로 재귀적 질의(recursive query)이고, dns.hongik.ac.kr은 자신이 직접 dns 서버에 질의를 해 정보를 가져오므로 반복적 질의(iterative query)에 속한다.

---

DNS 레코드

DNS 질의에 대한 답변도 일정한 틀이 있다. 일반적으로는

 

(Name, Value, Type, TTL)

이다. 이 중 TTL은 유효기간을 뜻한다. 캐싱된 후 캐시가 살아있는 기간이다.

Name과 Value는 Type에 따라 다르다.

 

A Type

A는 책임DNS가 질의된 호스트에 대한 IP주소를 알 때 이를 반환한다. Name은 호스트 이름, Value는 IP주소가 된다.

 

NS Type

NS Type은 해당DNS가 IP주소는 모르지만 해당 IP주소를 아는 책임DNS서버를 알 때 NS Type을 사용한다. 이 때 Name은 도메인, Value는 책임 DNS 서버의 호스트 이름이다. 위의 예시에서 네이버에 대한 책임DNS 서버와 이의 IP 주소를 반환한다.

 

CNAME Type

앞서 설명한 호스트 에일리어싱에 대하여 원래 호스트 이름을 찾게해준다. Name은 호스트 이름, Value는 정식 호스트 이름이다. 위에서 www.naver.com의 실제 호스트 이름은 www.naver.com.nheos.com임을 알 수 있다.

 

MX Type

메일 에일리어싱에 대해 원래 메일 호스트 이름을 찾게해준다. naver.com도 사실은 mx6.mail.naver.com의 메일 호스트 이름을 갖고 있었다.

 

이런 정보들을 자원 레코드(Resource Record, RR)이라고 칭한다.

 

DNS 메시지는 이렇게 생겼다.

 

식별자, 플래그, 질문수, 답변RR수, 추가RR수, 추가RR수는 총 12바이트의 헤더 영역이다.

식별자 - 질의에서 식별자가 만들어지고, 응답에 계속 복사된다.

플래그 - 몇 가지 설정들을 담는다. 질의/응답 구분, 책임서버임을 알리는 플래그, 재귀적 질의를 허용하는 플래그 등이 있다.

질문 - 현재 질의의 정보를 담는다. 질의하려는 호스트 이름과 질의하려는 타입을 나타낸다.

답변 - 질의에 대한 RR이 들어간다. 응답으로 여러 개의 RR을 보낼 수 있다.

책임 - 다른 책임 서버의 레코드를 담는다.

추가 - 다른 도움이 되는 레코드를 포함한다. MX Type에서 답변필드에 정식 호스트 이름을 제공하면서 추가정보 필드에 해당 호스트의 IP주소를 제공하는 식으로 사용된다.

개수 - 따라서 개수 필드에는 위 필드들에 대한 개수를 담는다.

---

도메인을 샀을 때

따라서 이제 도메인을 구매했다면 이 도메인을 DNS서버에 등록해야 외부에서 접근할 수 있다. 이것을 등록기관이 담당한다.

 

conx.co.kr 서버의 도메인을 구입했다고 하자.

그렇다면 등록기관에 해당 도메인에 대한 주책임 DNS 서버와 부책임 DNS 서버의 호스트 주소 및 IP 주소를 제공해야한다. 예를들면 dns1.conx.co.kr, dns2.conx.co.kr, 211.211.211.1, 211.211.211.2 등.. 그러면 등록기관은 conx.co.kr의 NS타입 레코드와 dns 서버에 대한 A타입 레코드를 DNS 시스템에 등록한다.

 

다만 꽤 번거로우므로 책임서버를 자동으로 등록해주는 대신 일정한 돈을 받는 서비스가 있다. (가비아 등)

이번에 팀프로젝트에서 구매한 도메인의 NS타입 레코드를 살펴보면 이렇게 뜬다.

현재는 루트53을 사용하기 때문에 DNS서버가 AWS의 것으로 바뀌었다. 원래는 가비아에서 구매했으므로 가비아의 DNS서버가 찍혔을 것이다.