[Amazon Route53] 동일한 도메인에 대해 외부/내부 액세스 분리를 위한 Split DNS 적용하기

개요

As-is

• DNS : AWS Route53을 이용하여 “example.com”이라는 public hosted zone 서비스 중.
• 네트워크 : On-Premise와 AWS는 Direct Connect로 연결되어 문제 없이 통신 중.

Problem

• On-Premise에서 접근하는 내부 직원 및 퍼블릭의 외부 직원이 공통으로 접속하는 웹 서버가 존재.
• public hosted zone에서 레코드가 등록되어, 내부 직원은 direct conenct로 연결되어 있음에도 불구하고 인터넷을 통해 외부망을 나갔다가 AWS로 들어옴. 불필요한 네트워크 오버헤드 발생.

To-Be

• 외부 직원은 퍼블릭에서도 문제 없이 웹 서버에 접속하되, 내부 직원은 내부망을 이용하여 Direct Connect를 통해 웹 서버에 접속 필요.
• 이를 위해 동일한 도메인에 대해 외부/내부 액세스 분리 필요 (Split-View DNS).

 

Split-Horizon DNS란? (= split dns = split-view dns)

내부/외부 네트워크에 따라 DNS 정보를 분리하는 DNS 구성. 쿼리를 보내는 클라이언트의 네크워크에 따라 동일한 도메인이 private ip 또는 public ip를 출력한다. 이를 통해 로컬 클라이언트 시스템이 인터넷을 통과할 필요 없이 로컬 네트워크를 통해 직접 서버에 액세스할 수 있으며, 더 적은 수의 네트워크 장치를 통과하면서 네트워크 대기 시간이 향상된다.

 

Route53을 이용한 Split-Horizon DNS 구성

Route53을 이용하여 Split-view DNS를 구성할 수 있다. 동일한 이름의 public / private hosted zone을 구성하고, 각 호스팅 영역에서 레코드를 생성한다. public hosted zone의 레코드는 인터넷 트래픽이 라우팅되는 방법을 제어하고, private hosted zone은 연결된 VPC (내부망)에서 라우팅되는 방법을 제어한다.

🚨 주의 🚨
단, VPC(내부망)에서 쿼리 시 일치하는 private hosted zone이 있지만 요청한 도메인 이름 및 type이 일치하는 레코드가 없는 경우 Resolver는 요청을 public DNS resolver로 전달하지 않는다. 그 대신 NXDOMAIN 오류를 리턴한다.

ex) 아래의 경우 private hosted zone에 연결된 VPC에서 “aaa.example.com” 쿼리 시 NXDOMAIN 리턴.
- private hosted zone “example.com” 내 “aaa.example.com”의 A type 레코드 없음.
- public hosted zone “example.com” 내 “aaa.example.com”의 A type 레코드 존재.

 

 

Split-Horizon DNS vs. Route53 IP 기반 라우팅 정책

Client IP를 기반으로 도메인을 라우팅한다는 개념은 동일하다. Route53의 IP기반 라우팅 정책을 사용하면 쿼리가 발생한 주소가 속한 CIDR 블록(서브넷)을 기반으로 DNS 라우팅을 미세 조정할 수 있으나 Public hosted zone에서만 적용할 수 있다. 제어 범위 내의 Resolver에서 쿼리하는지의 여부에 따라 트래픽을 전달하는 경우, Split Horizon DNS를 사용해야 한다. 즉, Resolver를 제어할 수 없는 CIDR 블록에 대해 IP-based Routing Policy를 이용한다.

[Amazon Route53] IP 기반 라우팅

Route53의 IP 기반 라우팅 정책을 이용하면 "내부망"으로 정의되는 대역이 추가/삭제되면 Route53 Location(CIDR 블록)을 추가/삭제하는 관리 point가 발생한다. Route53 Private/Public hosted zone & AD DNS 등 쿼리가 발생하는 클라이언트가 식별 가능하고 각 Resolver가 관리 범위 내에 있었기 때문에 R53의 IP 기반 라우팅 정책 대신 Split-Horizon DNS 구성을 선택하였다. 비용적인 측면에서도 Split-Horizon DNS가 유리하다. (2024.03 기준)

 

 

R53 Split-Horizon DNS 적용 방법

hosted zone을 다른 AWS 계정으로 마이그레이션하는 방법을 가이드하는 AWS의 공식 문서를 참조하여 Split-Horizon DNS를 적용하였다.

1. (사전 작업) 기존 public hosted zone의 레코드를 모두 다운로드

private hosted zone이 생성되는 순간부터 더이상 public hosted zone을 참조하지 않기 때문에 public의 모든 레코드를 private에 삽입하기 위해 AWS CLI를 이용하여 파일로 다운받았다. 

aws route53 list-resource-record-sets --hosted-zone-id {$public-hosted-zone} > ./hostedZone.json

2. (사전 작업) 1의 레코드 파일을 변환

동일한 이름의 private hosted zone이 생성되고 해당 zone에 원하는 레코드가 없으면 nxdomain 오류가 발생한다. nxdomain 오류가 발생하는 시간을 최소화하기 위해 hostedZone.json을 삽입하기 좋은 형태의 파일(createHostedZone.json)으로 변환한다.

(1) SOA, NS 레코드를 삭제

(2) AWS CLI " aws route53 change-resource-record-sets" 를 수행하기 위한 형태로 변환

import json

# 주어진 JSON 데이터
with open('./hostedzone.json', 'r') as f:
  input_json = json.load(f)

# 변환할 JSON 형식
output_json = {
  "Comment": "string",
  "Changes": []
}

# 기존 레코드 개수
print('기존 레코드 개수: ', len(input_json["ResourceRecordSets"]))

# 변환 작업 수행
for record_set in input_json["ResourceRecordSets"]:
  # Type이 "SOA" 또는 "NS"인 경우 삭제
  if record_set["Type"] in ["SOA", "NS"]:
    continue
  else:
    # 그 외의 경우는 변환 작업 수행
    change = {
      "Action": "CREATE",
      "ResourceRecordSet": record_set
    }
  output_json["Changes"].append(change)

print('변환 후 레코드 개수: ', len(output_json["Changes"]))

# 변환된 JSON을 파일로 저장
output_file_path = "createHostedZone.json"
with open(output_file_path, "w") as output_file:
  json.dump(output_json, output_file, indent=2)

 

3. 신규 private hosted zone 생성 및 일괄 레코드 삽입

동일한 이름의 private hosted zone을 생성하고 생성된 hosted zone에 아래 AWS CLI를 이용해 레코드를 일괄 삽입한다. 약 300개의 레코드 기준 수행 시간이 30초도 채 걸리지 않는다. 또한 A 타입의 Alias 레코드도 동일하게 잘 삽입된다.

private hosted zone 생성 시, nxdomain 오류 시간을 최소화하기 위해 하나의 VPC만 연결하였으며, 5번 과정까지 수행 후 나머지 VPC를 모두 연결하였다.

aws route53 change-resource-record-sets --hosted-zone-id {$private-hosted-zone} --change-batch file://./createHostedZone.json

4. (선택) public hosted zone(1)과 private hosted zone(3)의 레코드가 동일한지 검증

3에서 생성한 신규 private hosted zone과 기존의 public hosted zone의 레코드가 동일한지 검증한다. 아래 AWS CLI를 이용하여 private hosted zone 레코드를 파일로 다운로드한다.

aws route53 list-resource-record-sets --hosted-zone-id {$private-hosted-zone} > ./privateHostedZone.json

아래 파이썬 코드를 통해 동일한 값인지 확인하였다.

import json

def compare_json_files(file_path_a, file_path_b):
    try:
        with open(file_path_a, 'r', encoding='utf-8') as file_a, open(file_path_b, 'r', encoding='utf-8') as file_b:
            data_a = json.load(file_a)
            data_b = json.load(file_b)

            filtered_data_a = {
                "ResourceRecordSets": [record for record in data_a["ResourceRecordSets"] if record["Type"] not in ["NS", "SOA"]]
            }
            filtered_data_b = {
                "ResourceRecordSets": [record for record in data_b["ResourceRecordSets"] if record["Type"] not in ["NS", "SOA"]]
            }

            if filtered_data_a == filtered_data_b:
                print("두 JSON 파일은 동일합니다.")
            else:
                print("두 JSON 파일은 다릅니다.")
    except FileNotFoundError:
        print("파일을 찾을 수 없습니다.")
    except json.JSONDecodeError as e:
        print(f"JSON 디코딩 오류: {e}")
    except Exception as e:
        print(f"오류 발생: {e}")

file_path_A = './hostedZone.json'
file_path_B = './newHostedZone.json'
compare_json_files(file_path_A, file_path_B)

5. private hosted zone에서 분리가 필요한 레코드 값 수정

본 포스팅의 경우, private hosted zone의 레코드 값을 수정하여 abc.example.com의 값이 각각 아래와 같이 등록되었다. 

• public hosted zone : internet-facing NLB 엔드포인트 (A타입 Alias)
• private hosted zone : internal ALB 엔드포인트 (A타입 Alias)

6. AD 조건부 전달자 설정

AD DNS를 바라보는 온프렘 서버에서 기존처럼 "example.com"을 public으로 쿼리하지 않고 private하게 쿼리하고 내부망을 통해 통신되도록 조건부 전달자를 설정하였다. AD DNS에 조건부 전달자를 등록하자마자 전파에 소요되는 시간 없이 즉시 Route53의 private hosted zone으로 쿼리하였다. (기존에 쿼리하여 TTL 만큼의 캐시가 존재하는 경우 제외)

Route53 내  AD DNS와 통신하는 inbound endpoint 이미 존재하여 해당 내용은 생략하지만 최초 통신하는 경우에는 R53 inbound endpoint 생성 및 네트워크 구성, 보안그룹 규칙 설정 등의 과정이 필요하다.

 

참고

1. Wikipedia: Split-Horizon DNS
2. AWS Docs: Route53 > Split-view DNS
3. AWS Docs: Route53 > IP-based routing
4. AWS Blog: Introducing IP-based routing for Amazon Route 53
5. AWS Docs: Route53 > Migrating a hosted zone to a different AWS account