[AWS] Route 53 (2)

1. 프라이빗 호스팅 영역 (Private Hosted Zone)

프라이빗 호스팅 영역은 VPC 내에서 생성한 AWS 서비스들의 도메인에 대해 DNS 쿼리 정보가 담긴 컨테이너이다. 이는 외부 네트워크에 공개되지 않는다.

이를 사용하기 위해서는 VPC의 DNS resolution 과 DNS hostnames 를 활성화해야한다.

DNS resolution : 활성화시 AWS에서 제공하는 DNS 해석기를 사용한다.

DNS hostnames : 활성화시 AWS에서 제공하는 Public 과 Private hostname을 사용한다.

하나의 프라이빗 호스팅 영역은 다수의 VPC와 연결될 수 있으며, 타 계정의 VPC도 가능하다.

퍼블릭 호스팅 영역 쿼리보다 프라이빗 호스팅 영역 쿼리를 우선시한다.

2. Route 53 Resolver

프라이빗 호스팅 영역은 외부 네트워크에 공개되어 있지 않기 때문에 Route 53의 해석기 기능과 전달 규칙 (Forwarding Rules)가 필요하다.

Forwarding Rule : 다른 네트워크 환경에 도메인 쿼리를 전송하기 위한 정보이다.

Inbound Endpoint : 외부로부터 DNS 쿼리를 받을 수 있는 ENI 이다.

Outbound Endpoint : 외부 네트워크로 쿼리를 할 수 있는 ENI 이다.

3. 프라이빗 호스팅 영역과 Resolver 구성

1) 인프라 구성

구성할 인프라는 아래 그림과 같다.

한 회사가 하이브리드 환경에서 서비스를 제공하는 형태이다.

우측은 bind를 사용한 DNS 서비스를 하는 IDC 영역이라고 가정한다. idcneta.internal 도메인을 사용하며, dnssrv와 websrv 라는 서비스를 제공한다 .

좌측은 AWS EC2를 이용한 두개의 웹 서비스를 가동한다. awsneta.internal 도메인을 사용하며, 각각 websrv1 과 websrv2 이다.

awsneta.internal은 프라이빗 호스팅 영역이여서 외부에 공개되지 않는다. 우측의 DNS 서버는 awsneta.internal 에 관한 쿼리를 좌측의 Route 53 리졸버 인바운트 엔드포인트에게 넘겨준다. 좌측 VPC에서 idcneta.internal 을 DNS를 사용해 접근할 때에는 Route 53 아웃바운드 엔드포인트를 통해 쿼리를 우측 DNS 서버에 전송한다.

1. Route 53 서비스를 제외한 인프라를 구성한다. AWS-VPC은 DNS 호스트 네임을 활성화하고, 내부 두개의 서브넷은 서로 다른 가용영역에 생성한다.

2. IDC-DNSSRV 를 구성한다. 구성 내용은 다음과 같다.

   #---------------- /etc/named.conf ----------------#
   	listen-on port 53 { any ; };
   	allow-query { any; };
      	
   	# VPC의 dnssec이 비활성화이기 때문에 여기서도 비활성화
   	dnssec-enable no;
   	dnssec-validation no;
   #--------------------------------------------------#	
      
   #------------ /etc/named.rfc1912.zones ------------#
   zone "idcneta.internal" IN {
           type master;
           file "idcneta.zone";
   };
      
   zone "awsneta.internal" IN {
           type forward;
           forward only;
           forwarders { 10.70.1.250; 10.70.2.250; };
   };
      
   zone "ap-northeast-2.compute.internal" IN {
           type forward;
           forward only;
           forwarders { 10.70.1.250; 10.70.2.250; };
   };
   #--------------------------------------------------#	
      
   #------------ /var/named/idcneta.zone -------------#
   $TTL 1D
   @ IN SOA ns.idcneta.internal. admin.idcneta.internal. (
           20210927 1D 1H 1W 3H )
      
           IN NS   ns.idcneta.com.
   ns      IN A    10.80.1.100
   dnssrv  IN A    10.80.1.100
   websrv  IN A    10.80.1.200
   #--------------------------------------------------#
      
   $ sudo chown root.named /var/named/idcneta.zone
   

   10.70.1.250, 10.70.2.250 은 Route 53 리졸버 인바운드 엔드포인트의 주소가 될 것이다.

3. IDC-VPC 서브넷들의 DNS 리졸버 주소를 10.80.1.200, 8.8.8.8 로 변경한다. 인스턴스를 생성하기 전 VPC DHCP 옵션에서 설정해도 된다.

4. 서로 다른 VPC끼리 내부 통신하기 위해서는 두 VPC간 VPC Peering 연결 이 필요하다. Peering 생성 후 각각의 라우팅 테이블에서 상대방 VPC로의 트래픽을 Peering으로 라우팅한다.

5. awsneta.internal 도메인을 위한 Route 53 프라이빗 호스팅 영역을 생성하고 레코드를 생성한다.

   

6. Route 53 Resolver 엔드포인트를 구성한다.

   인바운드 : 10.70.1.250, 10.70.2.250 을 인바운드 엔드포인트로 설정한다.

   아웃바운드 : 10.70.1.251, 10.70.2.251 을 아웃바운드 엔드포인트로 설정한다.

   아웃바운드 엔드포인트 규칙은 다음과 같이 생성한다.

   

2) 트래픽 흐름

두 VPC간의 트래픽은 모두 VPC 피어링을 통해 전달된다.

IDC에서 awsneta 접근

IDC-WEB에서 web2.awsneta.internal 도메인 네임의 IP 질의

-> DNS서버는 awsneta.internal 도메인의 트래픽을 10.70.1.250 과 10.70.2.250 (Route53 인바운드 엔드포인트) 에 포워딩

-> Route53은 레코드를 보고 해당 도메인 네임의 IP가 10.70.2.100 임을 반환

awsneta에서 IDC 로 접근

AWS-WEB1 에서 websrv.idcneta.internal 도메인 네임의 IP 질의

-> Route 53은 아웃바운드 엔드포인트를 통해 쿼리를 10.80.1.100 (IDC-DNSSRV) 로 전달

-> IDC-DNSSRV는 도메인 네임의 IP가 10.80.1.200 임을 반환

CloudFormation Code