다수 서비스의 AWS 이전에 따른 Route53/DNS 쿼리 형태

INTRO

이전 게시물에서 온프레미스(On-Premise, 기업이 자체적으로 IT 인프라를 소유, 관리 및 운영하는 것) 도메인의 AWS 이전 형태에 따른 Route53(가용성과 확장성이 뛰어난 도메인 이름 시스템(DNS) 웹 서비스)/DNS(Domain Name System, 사람이 읽을 수 있는 도메인 이름을 머신이 읽을 수 있는 IP 주소로 변환하는 것) 설정 및 고려 사항에 대해 살펴봤습니다.

● 온프레미스 도메인의 AWS 이전 형태에 따른 Route53/DNS 설정 및 고려 사항 확인하기

Public Cloud로 시스템을 이전할 때, 기존 온프레미스 데이터 센터 또는 프라이빗 클라우드 등에 구축된 시스템이 하이브리드 클라우드 환경과 상호 연동되는데요. 상기 게시물을 통해 도메인을 통한 통신 흐름의 단순하고 효율적인 설계가 시스템 구축에 있어 가장 중요하다는 것을 알 수 있었습니다. 또한 기존 온프레미스 시스템의 일부 또는 전부를 AWS로 이전할 때, 이전하는 시스템의 도메인 형태(Sub-Domain(보조 도메인, URL로 전송하거나 계정 내의 IP 주소나 디렉토리로 포워딩되는 모데인 이름의 확장자) 또는 New-Domain)에 따른 상세한 설정 방법도 확인할 수 있었습니다.

이번 글에서는 다수 서비스를 AWS로 이전해 서비스 간의 도메인 호출이 필요한 경우, Route53 과 각 DNS 간의 쿼리가 어떤 형태로 이뤄지는지 자세히 살펴보겠습니다.

1. DNS 쿼리 방식

1) Recursive Query

DNS 재귀 쿼리(DNS Recursive Query)는 클라이언트가 도메인 이름을 IP 주소로 변환하기 위해 DNS 서버에 요청을 보낼 때, DNS 서버가 최종 응답을 얻기 위해 다른 DNS 서버들과 통신하는 과정을 말합니다. 해당 과정은 클라이언트가 직접 여러 DNS 서버와 통신하지 않고, 하나의 DNS 서버가 모든 작업을 대신 수행해 최종 결과를 클라이언트에게 반환하는 방식을 거치는데요. 아래에서 좀 더 자세히 알아보겠습니다.

(1) 클라이언트 : www.example.com에 대한 IP 주소를 로컬 DNS 서버에 요청합니다.

(2) 로컬 DNS 서버 : 캐시에 정보가 없으므로 루트 DNS 서버에 쿼리를 보냅니다.

(3) 루트 DNS 서버 : .com TLD(최상위 도메인, 도메인 이름의 마지막 마침표 뒤에 오는 모든 것) 서버의 IP 주소를 반환합니다.

(4) 로컬 DNS 서버 : .com TLD 서버에 쿼리를 보냅니다.

(5) TLD DNS 서버 : example.com 도메인의 권한이 있는 네임서버의 IP 주소를 반환합니다.

2. Iterative Query

DNS 반복 쿼리(DNS Iterative Query)는 클라이언트가 도메인 이름을 IP 주소로 변환하기 위해 여러 DNS 서버에 직접 쿼리를 보내는 방식입니다. 이 과정에서 각 DNS 서버는 알고 있는 정보를 클라이언트에게 반환하고, 클라이언트는 최종 IP 주소를 얻기 위해 여러 DNS 서버와 직접 통신합니다. 아래에서 좀 더 자세히 알아보겠습니다.

(1) 클라이언트 요청 : 클라이언트(예: 웹 브라우저)가 로컬 DNS Resolver(네트워크 내에서 DNS 쿼리를 처리하고, 이를 인터넷 상의 다른 DNS 서버에 전달하는 것)에 www.example.com의 IP 주소를 요청합니다.

(2) 로컬 DNS Resolver : 캐시에 정보가 없으면 루트 DNS 서버에 쿼리를 보냅니다.

(3) 루트 DNS 서버 : .com TLD 서버의 IP 주소를 반환합니다.

(4) 로컬 DNS Resolver : .com TLD 서버에 쿼리를 보냅니다.

(5) TLD DNS 서버 : example.com 도메인의 권한이 있는 네임서버의 IP 주소를 반환합니다.

(6) 로컬 DNS Resolver : 권한이 있는 네임서버에 쿼리를 보냅니다.

(7) 권한 있는 네임서버 : www.example.com에 대한 최종 IP 주소를 반환합니다.

(8) 로컬 DNS Resolver : 최종 IP 주소를 클라이언트에게 반환합니다.

3. 다수 서비스의 AWS 이전 DNS 아키텍처 예시

기존에 온프레미스 시스템을 구축해 사용하던 기업의 경우, 모든 서비스 시스템을 AWS 등의 Public Cloud로 이전하기가 쉽지 않습니다. 때문에 서비스 특성에 따라 일부는 온프레미스에 남기고, 일부는 Public Cloud로 이전하는 경우가 많습니다. 특히, 기존에 온프레미스 시스템에 DNS 서버를 두고 운영하는 기업의 서비스 사용자들이 DNS 서버(특히 내부 DNS 서버)를 통해 서비스 시스템 사용을 했다면, DNS 서버는 그대로 온프레미스에 남겨야 하는 요구사항이 있을 가능성이 높습니다.

이 경우 기존에 사용하던 서비스 도메인은 온프레미스에 남겨둔 상태에서 각각의 서비스별로 AWS 내부에서 사용할 용도의 Sub-Domain([그림 1]의*.aws.Aservice.com, *.aws.Bservice.com)을 Route53의 Private Hosted Zone으로 관리하고, 온프레미스 내부 DNS 서버에는 해당 Sub-Domain을 Forwarder 설정해 사용할 수 있습니다.

Sub-Domain이 아니라 New-Domain을 설정해 사용하는 경우 또한 위와 같은 방법으로 유사하게 설정할 수 있는데요. 이번 글에서는 Sub-Domain을 사용하는 예시만 살펴보겠습니다.

(1) 기존 온프레미스에서 사용자들이 A 서비스 시스템 용도로 사용했던 도메인은 *.Aservice.com으로, B 서비스 시스템 용도로 사용했던 도메인은 *.Bservice.com으로 가정

(2) 각각의 서비스 시스템 일부를 AWS로 이전하면서 AWS에서 관리할 도메인을 각각 AWS를 앞에 붙인 Sub-Domain 형태의 *.aws.Aservice.com, *.aws.Bservice.com으로 설정

(3) 온프레미스 사용자가 A 서비스용 AWS의 시스템 호출을 위해 *.aws.Aservice.com에 CNAME(Canonical Name, 도메인 주소를 또 다른 도메인 주소로 매핑 시키는 형태의 DNS 레코드) 형태로 *.aws.Aservice.com를 설정, 이 경우 *.aws.Aservice.com 호출이 가능하도록 온프레미스 내부 *.aws.Aservice.com를 추가

(4) (3)과 동일하게 B 서비스용 AWS 시스템 호출을 위한 forwarder를 온프레미스 내부 DNS에 추가

(5) A 서비스용 AWS VPC(Virtual Private Cloud, AWS 계정 사용자 전용 가상의 네트워크) 자원들이 기존 서비스용 도메인 및 AWS 상의 B 시스템 관리 도메인 호출이 가능하도록 Route53 Resolver Outbound Endpoint에 온프레미스 내부 DNS 서버를 target으로 *.Aservice.com, *.Bservice.com, *.aws.service.com을 포워딩 할 수 있도록 정책 설정

(6) (5)와 동일하게 B 서비스용 AWS VPC 자원들이 기존 서비스용 도메인 및 AWS 상의 A 시스템 관리 도메인 호출이 가능하도록 Route53 Resolver Outbound Endpoint에 정책 설정

(7) 온프레미스망과 각각의 서비스용 VPC는 통신할 수 있도록 연결되어 있어야 하며, 해당 글에서는 전용선 서비스인 DirectConnect로 연결되어 있다고 가정

4. 다수 서비스의 AWS Route53/DNS 쿼리 형태

앞서 살펴본 아키텍처에서 쿼리 형태를 상세히 살펴보기 위해 A 서비스 용도의 AWS EC2에서 B 서비스 시스템을 호출하는 사례를 알아봤습니다. 이 경우, 실제 각각의 쿼리가 어떤 서버에서 어떤 형태로 전달, 응답되는지에 대한 상세한 내용을 아래 [그림 2]와 같이 도식화할 수 있습니다.

[그림 2]에서는 경로가 단순하게 화살표로 표시되어 있지만, 통신 경로 상 여러 장비를 거칠 수 있습니다. 특히 AWS 내부 또는 온프레미스에 보안 장비 등이 있는 경우, DNS 통신에 문제가 생기지 않도록 사전에 허용해 주는 절차가 필요합니다. 예를 들어, Route53 Resolver Endpoint에 설정되는 Security Group이나 온프레미스 내부 DNS 서버 앞 단의 방화벽, 경우에 따라 AWS DirectConnect 경로의 방화벽 등이 있을 수 있으며 망 구성에 따라 단순 정책으로 관리되는 보안 장비 외의 경로상 IDS/IPS 등을 거치는 경우도 있습니다.

실제 온프레미스에서 AWS로 이전되는 더 많은 서비스가 있을 수 있지만 일반적으로 2개를 넘는 서비스 호출이 필요한 경우는 많지 않습니다. 게다가 모든 케이스를 상세히 다루기에는 너무 길고 복잡해질 수 있으므로 이번 글에서는 2개 서비스간 호출에 대해서만 살펴보겠습니다.

(1) 서비스 용도의 AWS VPC에 있는 EC2에서 B 서비스 시스템 호출을 위한 도메인 B.Aservice.com을 질의

(2) AWS의 Local DNS에서 받은 EC2 질의는 *.Aservice.com 도메인 정보가 AWS의 Local DNS에서는 온프레미스의 내부 DNS로 포워딩 되도록 설정되어 있으므로 질의를 온프레미스 내부 DNS로 전달

(3) 온프레미스 내부 DNS에 B.Aservice.com에 대한 CNAME 레코드가 A.aws.Bservice.com으로 설정되어 있으므로 이를 AWS Local DNS로 회신

(4) AWS Local DNS는 응답 받은 A.aws.Bservice.com에 대해 설정된 내용을 확인. 마찬가지로 온프레미스 DNS로 포워딩 설정된 *.aws.Bservice.com 관련 질의이므로 온프레미스 내부 DNS로 전달

(5) A.aws.Bservice.com에 대한 질의를 받은 온프레미스 내부 DNS는 해당 질의를 B 서비스 용도의 AWS Route53으로 전달

(6) B 서비스 용도의 AWS Route53은 해당 도메인의 IP 정보를 온프레미스 내부 DNS로 회신

(7) 온프레미스 내부 DNS는 응답 받은 IP 정보를 질의 받았던 AWS Local DNS로 회신

(8) AWS Local DNS는 응답 받은 IP 정보를 질의 받았던 AWS EC2로 회신

OUTRO

사용자는 보다 많은 온프레미스 워크로드를 AWS와 같은 Public Cloud로 이전해 서비스나 비용 측면에서 이점을 얻을 수 있습니다. 하지만 엔터프라이즈 워크로드의 경우, 모든 서비스를 Public Cloud로 이전하는 것이 결코 쉽지만은 않은데요. 이전을 진행할 경우, 온프레미스의 DNS 뿐만 아니라 AWS로 이전된 각 서비스별 AWS Route53으로 도메인 구성/운용이 복잡해질 수 있으며, 문제가 발생할 경우 어떤 경로를 확인해야 하는지 쉽게 파악하기 어려운 경우가 많습니다.

최근 AWS에서 Route53의 DNS query logging(DNS 트래픽에 대한 상세 데이터를 수집하는 과정)이나 DNS firewall(DNS 방화벽, DNS 트래픽만 모니터링하고 DNS 공격으로부터 IT 환경을 보호하도록 특별히 설계된 것) 등 DNS와 관련된 다양한 기능들을 업데이트 하면서, 과거에 비해 DNS 구성 또는 운영 시 사용자가 확인/제어할 수 있는 포인트가 많아졌습니다. 또한 다양한 활용 사례도 찾아볼 수 있게 되었습니다.

사용자가 AWS의 다양한 기능에 대한 이해도가 높아질수록 각각의 구성 아키텍처에 따른 장/단점, 발생 비용 등을 검토해 최적의 활용 방안을 선택할 수 있으며, 이를 통해 운영/관리에 드는 노력과 비용을 절감할 수 있습니다.

[참고문헌]

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html /

https://aws.amazon.com/ko/blogs/korea/log-your-vpc-dns-queries-with-route-53-resolver-query-logs

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-overview.html