DNS란

DNS 서비스

DNS는 Domain Name System의 약어로, 네트워크 통신으 위한 주소 체계를 문자 형태인 도메인으로 매핑하여 연결하는 서비스를 의미한다. 여기에서 네트워크 통신 주소는 일반적으로 IP 주소를 사용하는데, 한마디로 IP 주소를 문자 형태의P 주소를 사용하는데, 한마디로 IP 주소를 문자 형태의 도메인 주소로 매핑해서 사용하는 서비스를 의미한다.

예를 들어 구글 웹 페이지에 접속한다고 가정하면, 구글 웹 서버의 IP 주소로 접속해야 한다. 하지만 우리는 IP 주소가 아닌 google.com이라는 문자로 된 주소로 접속한다. DNS 서비스 덕분에 바로 이런 google.com이라는 도메인 주소로 구글 웹 페이지에 접근할 수 있다.

그렇다면 도메인 주소를 활용한 웹 서버 접근은 어떤 단계를 거치는가?

1. 웹 서버의 IP 주소를 도메인 주소로 사용하고자 ongja.com 도메인을 구매하고 등록한다. 그러면 DNS 서버는 ongja.com의 IP 주소가 무엇인지 알고 정보를 기록해둔다.

2. 사용자는 ongja.com이라는 도메인 주소가 어떤 IP 주소인지 모르고 있으므로 해당 정보를 확인하는 작업이 필요하다.

3. 사용자는 도메인 주소의 IP 주소를 확인하기 위해 DNS 서버에 ongja.com의 도메인 주소를 요청하고 응답받는다. 이때 UDP 53번 포트를 사용하는 DNS 프로토콜을 이용하여 통신한다. 그러면 사용자는 ongja.com에 대한 IP 주소가 무엇인지 알 수 있다.

4. 사용자는 ongja.com의 IP 주소를 알아냈기 때문에 해당 IP 주소로 통신한다.

물론 DNS 서버는 용도에 따라 종류가 다양하며 이들 사이에 복잡한 통신 과정이 있다.

도메인 구조

루트 도메인

우리가 사용하는 모든 도메인 주소의 가장 마지막에는 온점이 있는데, 일반적으로 이 부분은 생략하고 사용한다. 여기에서 마지막에 위치하는 온점을 루트 도메인이라고 한다.

탑 레벨 도메인

도메인 주소에서 가장 상위에 위치한 도메인을 탑 레벨 도메인이라고 하며, 줄여서 TLD(Top Level Domain)라고 한다.

세컨드 레벨 도메인

TLD 다음에 위치한 두 번째 도메인 영역을 세컨드 레벨 도메인이라고 하며, 줄여서 SLD(Second Level Domain)라고 한다. 이런 SLD는 상위 TLD에서 유일하게 존재하고 식별하는 도메인 영역이다. 일반적으로 도메인 이름은 SLD와 TLD를 합친 형태로 표현한다.

서브 도메인

도메인을 용도에 따라 앞에 명칭을 부여해서 분류할 수 있는데, 이를 서브 도메인이라고 한다.

DNS 서버 종류

도메인 구조를 루트 도메인, 탑 레벨 도메인, 세컨드 레벨 도메인, 서브 도메인으로 구분하는 가장 큰 이유는 영역별 도메인을 관리하는 주체를 분리하기 위해서이다. 도메인은 DNS 네임 서버로 관리하는데, 이때 도메인 영역별로 DNS 네임 서버를 분류해서 관리한다.

루트 네임 서버

루트 도메인을 관리하는 DNS 서버를 루트 네임 서버라고 한다. DNS 요청에 대해 TLD에 해당하는 네임 서버 정보를 응답한다. 루트 네임 서버는 전 세계에 13개만 존재한다.

TLD 네임 서버

도메인 이름의 최상위 영역인 TLD를 관리하는 DNS 서버로, TLD 네임 서버라고 한다. TLD 영역에서 식별되는 모든 SLD를 관리하여 DNS 요청에 대해 SLD 네임 서버 정보를 응답한다. 예를 들어 .com이라는 TLD 네임 서버는 .com 내에 있는 google.com 도메인을 관리하는 SLD 네임 서버 정보를 알고 있다. 해당 도메인에 대한 DNS 요청이 있으면 SLD 네임 서버 주소를 알려준다.

SLD 네임 서버

실질적인 도메인 이름을 관리하는 DNS 서버로, SLD 네임 서버(권한 있는 네임 서버)라고 한다. 이런 SLD 네임 서버는 실제 도메인의 최종 관리 서버로 권한이 있는 네임 서버라고 한다. 도메인 주소에 대한 IP 주소를 확인하는 가장 마지막 단계이다.

DNS 해석기

사용자와 네임 서버 사이에서 중계자 역할을 수행하는 목적으로 DNS 해석기가 있다. 사용자가 DNS 해석기로 DNS 요청을 하면, DNS 해석기가 DNS 네임 서버와 정보를 주고받아 도메인 주소를 해석하여 최종적으로 IP 주소를 사용자에게 알려준다.

DNS 통신 흐름

1. 사용자 PC에서 blog.cloudneta.net이라는 도메인 주소의 IP 주소를 알기 위해 DNS 서버에 질의한다. 여기에서 DNS 서버는 DNS 해석기를 이용하여 다양한 네임 서버와 통신하는 중계자 역할을 수행한다.

2. 기본적으로 DNS 해석기는 전 세계에 있는 루트 네임 서버의 주소를 알고 있다. 해당 루트 네임 서버에 blog.cloudneta.net 도메인 주소의 IP 주소를 물어본다. 여기에서 루트 네임 서버는 blog.cloudneta.net이라는 도메인 주소를 알지 못하지만 .net의 TLD 네임 서버는 알고 있기 때문에 해당 정보를 DNS 해석기에 전달한다.

3. 그러면 DNS 해석기는 .net에 해당하는 TLD 네임 서버에 blog.cloudneta.net 도메인 주소의 IP 주소를 물어본다. 여기에서 TLD 네임 서버는 blog.cloudneta.net이라는 도메인 주소를 알지 못하지만 cloudneta.net의 SLD 네임 서버는 알고 있어 해당 정보를 DNS 해석기에 전달한다.

4. 다시 DNS 해석기는 cloudneta.net에 해당하는 SLD 네임 서버에 blog.cloudneta.net 도메인 주소의 IP 주소를 물어본다. 이 SLD 네임 서버는 도메인 주소의 최종 정보가 있는 '권한이 있는 네임 서버'로, blog.cloudneta.net에 대한 IP 주소를 DNS 해석기에 전달한다.

5. DNS 해석기는 blog.cloudneta.net에 대해 최종적으로 해석한 IP 주소를 사용자 PC에 전달한다. 이것으로 사용자 PC는 blog.cloudneta.net 도메인 주소의 IP 주소를 알게 되어 해당 IP 주소로 통신한다.

DNS 레코드 유형

DNS 레코드는 도메인에 대한 요청 처리 방법을 정의한 것으로, 용도에 따라 DNS 레코드 유형을 분류한다.

A 레코드 유형

도메인 이름을 IPv4 주소로 매핑하는 가장 기본적인 DNS 레코드 유형이다.
다음 형태로 표현한다.
blog.cloudneta.net A 52.219.60.13
blog.cloudneta.net이라는 도메인 주소로 질의하면 IPv4 주소인 52.219.60.13으로 응답한다.

AAAA 레코드 유형

도메인 이름을 IPv6 주소로 매핑하는 DNS 레코드 유형이다. A 레코드 유형의 IPv6 버전이라고 생각하면 된다. 다음 형태로 표현된다.
blog.cloudneta.net AAAA 2001:A10::2001
blog.cloudneta.net이라는 도메인 주소로 질의하면 IPv6 주소인 2001:A10::2001로 응답한다.

NS 레코드 유형

도메인 이름의 네임 서버 주소로 매핑하는 DNS 레코드 유형이다.
다음 형태로 표현한다.
net NS a.gtld-servers.net.
blog.cloudneta.net이라는 도메인 주소로 질의하면 .net의 TLD 네임 서버 주소인 a.gtld-servers.net. 이라는 도메인 주소로 응답한다.

CNAME 레코드 유형

도메인 이름의 별칭을 지정하는 DNS 레코드 유형으로, 다른 도메인 이름을 정의한다. 다음 형태로 표현한다.
www.cloudneta.net CNAME cloudneta.net
www.cloudneta.net이라는 도메인 주소로 질의하면 cloudneta.net의 도메인 주소로 응답한다.

이외에도 다양한 DNS 레코드 유형이 있으며, 이런 DNS 레코드 유형은 DNS 서버에서 다양하게 정의하고 동작한다.

Amazon Route 53 서비스

Amazon Route 53 서비스는 AWS에서 제공하는 관리형 DNS 서비스이다.

Amazon Route 53의 주요 기능

Amazon Route 53은 다음 그림과 같은 형태의 아이콘으로 표현한다. Amazon Route 53은 주로 도메인 이름 등록과 호스팅 영역 생성, 레코드 작성 같은 기능을 제공한다.

도메인 이름 등록

도메인 이름을 사용하려면 도메인 이름을 등록하는 절차가 필요하다. 도메인을 등록하려면 전 세계에 위치한 네임 서버에 도메인 이름을 사용한다고 알려야 하는데, 이 작업은 개인이 아닌 등록대행소에서 관장한다. 즉, 사용자가 도메인 등록대행소에 도메인 이름 등록을 요청하면 도메인 등록 작업을 대행하는 것이다. 도메인 등록대행소로 국내외에 다양한 웹 사이트가 존재하는데 Amazon Route 53도 도메인 등록대행소 역할을 수행한다.

도메인 이름을 등록하는 작업을 살펴보기 전에 도메인 영역별 네임 서버를 관리하고 등록을 관장하는 단체들을 알아보자. 가장 상위에 ICANN이라는 비영리 단체가 루트 네임 서버를 관리하고 TLD 네임 서버를 등록하는 역할을 수행한다. 다음으로 '등록소'라고 하는 기관이나 기업들이 TLD 네임 서버를 관리하고 권한 있는 네임 서버를 등록하는 역할을 수행한다.

이런 구성에서 Amazon Route 53의 도메인 등록 대행소는 도메인 이름의 TLD에 해당하는 등록소로 도메인 등록 작업을 수행한다. 그래야 앞서 설명한 DNS 통신 흐름에 따라 최종적인 서비스가 가능하다.

호스팅 영역 생성

Amazon Route 53으로 호스팅 영역을 생성하여 네임 서버를 관리할 수 있다. 이렇게 호스팅 영역을 생성해야 Amazon Route 53이 등록된 도메인 이름에 대한 권한 있는 네임 서버이자 SLD 네임 서버의 역할을 수행할 수 있다. 호스팅 영역의 네임 서버들은 고가용성을 위해 다수의 서버로 구성하는데, 마치 네임 서버들의 Zone을 구성하는 개념이다.

레코드 작성

Amazon Route 53은 DNS 레코드를 정의하여 도메인에 대한 요청 처리 방법을 정의할 수 있는데, 이런 DNS 레코드는 다양한 형태의 라우팅 정책을 연결하여 도메인 요청에 대한 응답 방식을 정의할 수 있다.

Amazon Route 53의 라우팅 정책

단순 라우팅 정책

단순 라우팅 정책은 도메인에 대해 특정 대상을 지정하는 방식으로 여러 대상이 있으면 랜덤한 대상을 선택하고 응답한다. 예를 들어 ongja.com이라는 도메인의 A 레코드가 10.1.1.1과 10.1.1.2로, 단순 라우팅 정책으로 레코드를 구성하면 DNS 요청에 대해 둘 중 하나의 IP 주소로 랜덤하게 응답한다.

가중치 기반 라우팅 정책

단순 라우팅 정책이 랜덤하게 대상을 지정했다면 가중치 기반 라우팅 정책은 대상의 가중치를 지정하여 비중에 따라 대상을 선택하고 응답한다. 참고로 가중치는 0~255 범위에서 설정하는데, 대상별 가중치 값을 합산한 전체 가중치를 대상별 가중치로 나누어 비중을 부여한다. 예를 들어 ongja.com이라는 도메인의 A 레코드가 10.1.1.1과 10.1.1.2로, 가중치 기반 라우팅 정책으로 레코드를 구성할 때 10.1.1.1의 가중치가 90이고 10.1.1.2의 가중치가 10이라고 하자. 그러면 DNS 요청에 대해 10.1.1.1로 응답하는 비중은 90/100이고 10.1.1.2로 응답하는 비중은 10/100이 된다.

지연 시간 기반 라우팅 정책

지연 시간 기반 라우팅 정책은 다수의 리전에 대상 자원이 있으면 사용자와 인접한 리전을 기준으로 대상 자원의 리전까지 지연 시간을 파악해서 낮은 지연 시간의 대상을 선택하고 응답한다. 예를 들어 ongja.com이라는 도메인의 A 레코드가 10.1.1.1과 10.1.1.2로, 지연 시간 기반 라우팅 정책이라고 하자. 이때 10.1.1.1은 도쿄 리전에 위치하고 10.1.1.2는 런던 리전에 위치한다고 가정하면, 사용자 위치상 인접한 리전과 대상 자원의 리전까지 지연 시간을 파악한다. 이때 도쿄 리전은 50ms의 지연 시간을 갖고 런던 리전은 230ms의 지연 시간을 갖는다면 DNS 요청에 대해 도쿄 리전에 속한 대상으로 응답한다.

장애 조치 라우팅 정책

장애 조치 라우팅 정책은 다수의 대상 자원에 대해 액티브와 패시브로 분류하고 대상 상태를 주기적으로 검사하여 액티브 대상을 선택하고 응답한다. 액티브 대상이 통신 불가능할 때는 패시브 대상을 액티브로 승격하여 대상 경로로 라우팅한다.

그 밖에 사용자 PC가 지정하는 DNS 서버의 지리적으로 인접한 리전에 위치한 대상으로 경로를 선택하는 지리 위치 라우팅 정책, 지리 위치 라우팅과 형태가 동일하지만 영향도를 조정하는 바이어스(bias)라는 값을 사용하여 제어하는 지리 근접 라우팅 정책이 있다. 또한 DNS 요청에 대해 다수의 값을 반환할 수 있는 다중 값 응답 라우팅 정책도 있다.