[AWS 교과서] 7장 - AWS 고급 네트워킹 서비스(1)

 

AWS가 제공하는 고급 네트워킹 기능 중 AWS의 관리형 DNS 서비스인 Amazon Route 53을 살펴보기에 앞서

DNS가 무엇인지부터 이해해 보자!

 

DNS란

 

 

DNS 서비스

 

DNS는 Domain Name System의 약어로, 네트워크 통신을 위한 주소 체계를 문자 형태인 도메인으로 매핑하여 연결하는 서비스이다

 

=> 네트워크 통신 주소는 일반적으로 IP 주소를 사용하는데, 한마디로 IP 주소를 문자 형태의 도메인 주소로 매핑해서 사용하는 서비스를 의미한다

 

 

ex. 도메인 주소를 이용한 통신 과정을 살펴보면

 

1. 웹 서버의 IP 주소를 도메인 주소로 사용하고자 jungyo.com 도메인을 구매하고 등록한다

 

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

 

3. 사용자는 도메인 주소의 IP 주소를 확인하기 위해 DNS 서버에 jungyo.com의 도메인 주소를 요청하고 응답 받음

=> UDP 53번 포트를 사용하는 DNS 프로토콜을 이용하여 통신함 (사용자가 jungyo.com에 대한 IP 주소를 알게 됨)

 

4. 사용자는 jungyo.com의 IP 주소를 알아냈기 때문에 해당 IP 주소로 통신 가능!

 

(실제로는 사이사이에 복잡한 통신 과정이 있음)

 

도메인 구조

 

앞서 설명한 도메인 주소를 자세히 살펴보면 영역별로 도메인을 분류할 수 있다

 

blog.cloudneta.net. 을 살펴보면

 

 

      blog.                 cloudneta.                    net                     .                  
서브 도메인     세컨드 레벨 도메인    탑 레벨 도메인   루트 도메인

                                   (SLD)                     (TLD)

 

 

이렇게 나눠진다

 

 

1. 루트 도메인 

우리가 사용하는 모든 도메인 주소의 가장 마지막에는 온점이 있는데, 일반적으로 이 부분은 생략하고 사용한다

=> 마지막에 위치하는 온점을 루트 도메인이라고함

 

2. 탑 레벨 도메인

 

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

 

.net이 TLD에 해당하고 이런 TLD는 종류가 다양한데, 우리가 흔히 접하는".com", "co.kr", ".org" 등이 있다

 

3. 세컨드 레벨 도메인

 

TLD 다음에 위치한 두 번째 도메인 영역을 세컨드 레벨 도메인이라고 하며, 줄여서 SLD(Second Level Domain)라고 한다

(cloudneta가 SLD에 해당함)

 

=> 이런 SLD는 상위 TLD에서 유일하게 존재하고 식별하는 도메인 영역이다

(일반적으로 도메인 이름은 SLD와 TLD를 합친 형태로 표현함 -> 예시에서 cloudneta.net이라는 도메인 이름)

 

4. 서브 도메인

 

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

 

예를 들어 blog.cloudneta.net이나 test.cloudneta.net처럼 앞의 blog와 test가 서브 도메인임

 

DNS 서버 종류

 

위의 예시처럼 도메인 구조를 구분하는 가장 큰 이유는 영역별 도메인을 관리하는 주체를 분리하기 위해서이다!

 

도메인은 DNS 네임 서버로 관리하는데, 이 때 도메인 영역별로 DNS 네임 서버를 분류해서 관리한다

 

이런 DNS 서버 종류들을 살펴보자

 

1. 루트 네임 서버

 

루트 도메인을 관리하는 DNS 서버를 루트 네임 서버라고 한다

 

=> DNS 요청에 대해 TLD에 해당하는 네임 서버 정보를 응답 

 

전 세계에 루트 네임 서버는 13개만 존재
=> (a.root-servers.net. ~ m.root-servers.net.)

 

2. TLD 네임 서버

 

도메인 이름의 최상위 영역인 TLD를 관리하는 DNS 서버로, TLD 네임 서버라고 한다

 

=> TLD 영역에서 식별되는 모든 SLD를 관리하여 DNS 요청에 대해 SLD 네임 서버 정보를 응답한다

 

예를 들어 .com이라는 TLD 네임 서버는 .com 내에 있는 google.com 도메인을 관리하는 SLD 네임 서버 정보를 알고 있다

 

=> 해당 도메인에 대한 DNS 요청이 있으면 SLD 네임 서버 주소를 알려준다

 

3. SLD 네임 서버

 

실질적인 도메인 이름을 관리하는 DNS 서버로, SLD 네임 서버(권한 있는 네임 서버)라고 한다

 

=> SLD 네임 서버는 실제 도메인의 최종 관리 서버로 권한이 있는 네임 서버라고 한다

(도메인 주소에 대한 IP 주소를 확인하는 가장 마지막 단계)

 

4. DNS 해석기

 

사용자와 네임 서버 사이에서 중계자 역할을 수행하는 목적으로 DNS 해석기가 있다

 

=> 사용자가 DNS 해석기로 DNS 요청을 하면, DNS 해석기가 DNS 네임 서버와 정보를 주고 받아 도메인 주소를 해석하여 최종적으로 IP 주소를 사용자게에 알려줌!

 

 

영역별로 도메인 이름을 관리하는 루트 네임 서버, TLD 네임 서버, SLD 네임 서버가 있고
DNS 해석기를 이용하여 단계별로 DNS 요청과 응답을 수행하여 도메인 주소의 최종 IP 주소를 확인한다

 

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 레코드 유형을 분류한다

 

다양한 DNS 레코드 유형이 있지만, 보편적으로 사용하는 DNS 레코드를 몇 가지 알아보자!

 

 

1. A 레코드 유형

 

도메인 이름을 IPv4 주소로 매핑하는 가장 기본적인 DNS 레코드 유형이다

 

blog.cloudneta.net A 52.219.60.13 과 같은 형태로 표현한다

 

=> blog.cloudneta.net이라는 도메인 주소로 질의하면 IPv4 주소인  52.219.60.13으로 응답한다

 

2. AAAA 레코드 유형

 

도메인 이름을 IPv6 주소로 매핑하는 DNS 레코드 유형이다

(A 레코드 유형의 IPv6 버전이라고 생각하면 됨)

 

blog.cloudneta.net AAAA 2001:A10::2001 과 같은 형태로 표현한다

 

=> blog.cloudneta.net이라는 도메인 주소로 질의하면 IPv6 주소인  2001:A10::2001으로 응답한다

 

3. NS 레코드 유형

 

도메인 이름의 네임 서버 주소로 매핑하는 DNS 레코드 유형이다

 

net NS a.gtld-servers.net. 과 같은 형태로 표현한다

 

=> blog.cloudneta.net이라는 도메인 주소로 질의하면 .net의 TLD 네임 서버 주소인 a.gtld-servers.net. 이라는 도메인 주소로 응답한다

 

4. 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으로 호스팅 영역을 생성하여 네임 서버를 관리할 수 있다

 

=> 이렇게 호스팅 영역을 생성해야 Amazon Route 53이 등록된 도메인 이름에 대한 권한 있는 네임 서버이자 SLD 네임 서버의 역할을 수행할 수 있다

 

(호스팅 영역의 네임 서버들은 고가용성을 위해 다수의 서버로 구성하는데, 마치 네임 서버들의 Zone을 구성하는 개념임)

 

레코드 작성

 

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

 

Amazon Route 53의 라우팅 정책

 

앞서 설명한 것처럼 Amazon Route 53에는 DNS 요청에 어떻게 응답할지 정의하는 다양한 라우팅 정책이 있다

 

1. 단순 라우팅

 

단순 라우팅 정책은 도메인에 대해 특정 대상을 지정하는 방식으로

 

만약 jungyo.com이라는 도메인의 A 레코드가 10.1.1.1과 10.1.1.2 처럼 여러 대상이 있다면 랜덤한 대상을 선택하고 응답한다

 

2. 가중치 기반 라우팅 정책

 

가중치 기반 라우팅 정책은 대상의 가중치를 지정하여 비중에 따라 대상을 선택하고 응답한다

 

만약 jungyo.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이 된다

 

3. 지연 시간 기반 라우팅 정책

 

지연 시간 기반 라우팅 정책은 다수의 리전에 대상 자원이 있으면 사용자와 인접한 리전을 기준으로 대상 자원의 리전까지 지연 시간을 파악해서 낮은 지연 시간의 대상을 선택하고 응답한다

 

만약 jungyo.com이라는 도메인의 A 레코드가 10.1.1.1과 10.1.1.2로, 지연 시간 기반 라우팅 정책이라고 생각해보면

(10.1.1.1은 도쿄 리전에 위치하고 10.1.1.2는 런던 리전에 위치한다고 가정)

 

사용자 위치상 인접한 리전과 대상 자원의 리전까지 지연 시간을 파악하여

도쿄 리전은 50ms의 지연 시간을 갖고 런던 리전은 230ms의 지연 시간을 갖는다면 DNS 요청에 대해 도쿄 리전에 속한 대상으로 응답한다

 

4. 장애 조치 라우팅 정책

 

장애 조치 라우팅 정책은 다수의 대상 자원에 대해 액티브와 패시브로 분류하고 대상 상태를 주기적으로 검사하여 액티브 대상을 선택하고 응답한다

 

=> 액티브 대상이 통신 불가능할 때는 패시브 대상을 액티브로 승격하여 대상 경로로 라우팅

 

그 밖에 사용자 PC가 지정하는 DNS 서버의 지리적으로 인접한 리전에 위치한 대상으로 경로를 선택하는 지리 위치 라우팅 정책, 지리 위치 라우팅과 형태가 동일하지만 영향도를 조정하는 바이어스라는 값을 사용하여 제어하는 지리 근접 라우팅 정책이 있다

또한, DNS 요청에 대해 다수의 값을 반환할 수 있는 다중 값 응답 라우팅 정책도 있다

Amazon Route 53은 다양한 라우팅 정책을 제공한다는 정도만 이해하자!

 

도메인 이름 생성하기

 

Amazon Route 53 실습에서는 자신만의 도메인 이름이 필요하다!

 

=> 실습에 앞서 사전 작업으로 도메인 이름을 생성하는 작업을 진행해보자

 

 

도메인 이름을 생성하고 Amazon Route 53의 호스팅 영역에 등록할 때는 과금이 발생하기 때문에

 

1. 무료 도메인 이름 생성 사이트 활용

(http://bit.ly/cnba0502)

 

2. Amazon Route 53을 사용한 유로 도메인 이름 생성

 

를 추천 했지만..

 

현재 1번 사이트가 기술적 이슈로 사용을 못한다고 해서

 

https://xn--220b31d95hq8o.xn--3e0b707e/

내도메인.한국 - 한글 무료 도메인 등록센터

 

저는 여기서 진행을 했습니다!

 

생성을 완료하고 AWS Route 53 서비스에 접속하여 호스팅 영역 메뉴를 선택한 후 생성한 도메인을 클릭하여 호스팅 영역에 진입한다

 

 

생성한 도메인의 호스팅 영역에서 가지고 있는 레코드를 확인하고, 테스트용 레코드를 생성하기 위해

레코드 생성을 누른다

 

도메인에 기본적으로 있는 레코드를 확인해 보면, 먼저 NS 레코드 유형으로 네임 서버의 도메인 주소가 있다

 

=> 즉, 도메인의 권한 있는 네임 서버 도메인 주소로 최종적인 DNS 응답을 처리해 주는 서버들이다

 

SOA 레코드 유형으로 도메인 호스팅 영역의 주요 정보를 담고 있는 레코드도 있다!

 

 

다음과 같이 설정하고 테스트용 레코드를 생성한다

 

 

생성된 레코드의 의미는

test.jungyo.kro.kr이라는 도메인 이름은 A 레코드 유형으로 IPv4 주소를 8.8.8.8로 매핑한 단순 라우팅 정책이다

 

=> test.jungyo.kro.kr 도메인 이름을 요청하면 8.8.8.8의 IP 주소를 반환한다

 

확인을 위해  각자 사용자 PC의 CMD나 터미널에서 명령어를 실행해본다

# [test.jungyo.kro.kr]으로 nslookup 테스트

nslookup test.jungyo.kro.kr

# [test.jungyo.kro.kr]으로 ping 테스트

ping test.jungyo.kro.kr

 

근데 이제!!

 

Amazon Route 53에서 직접 등록한 도메인이 아니면 호스팅 영역을 생성할 때 만들어지는

네임 서버들로 도메인을 생성한 사이트에서 변경해줘야 하는데

 

내가 사용한 사이트는 네임 서버 변경을 지원하지 않는다는 생각도 못한 이슈가 있었다...

 

그래서 직접 생성한 사이트의 도메인 설정에서 A 레코드를 생성하여 확인하였다는 슬픈 전설이 남게 되었다

 

 

 

하여튼 이렇게 확인이 되었고

 

각자 도메인의 호스팅 영역에서 앞서 생성한 레코드를 체크한 후 레코드 삭제를 누른다