beautifulsoups.dev
Published on

AWS Route 53 서브도메인 NS 위임 오류 7분 해결

Authors

서브도메인을 Route 53로 분리 운영하려고 NS 위임을 걸었는데, 인증서 발급(ACM), CloudFront, 외부 SaaS 도메인 검증에서 계속 실패하거나 dig 결과가 엉뚱한 네임서버로 향하는 경우가 있습니다. 이 문제는 대부분 부모 존에 등록된 NS 레코드가 실제 서브도메인 호스티드 존의 네임서버와 불일치하거나, 퍼블릭/프라이빗 호스티드 존을 혼동했거나, 동일 서브도메인에 중복 위임이 걸린 케이스입니다.

이 글은 “7분 안에” 원인 분류부터 수정까지 끝내는 실전 절차로 구성했습니다. DNS는 전파가 필요하지만, 오류의 90%는 전파 이전에 로컬에서 바로 판별할 수 있습니다.

0. 문제 증상 빠르게 분류하기(1분)

다음 중 무엇에 해당하는지 먼저 고릅니다.

  • dig sub.example.com NS 결과가 Route 53 네임서버가 아니다
  • dig +trace sub.example.com에서 부모 존에서 이미 다른 곳으로 위임 중이다
  • Route 53 콘솔에서는 NS를 넣었는데도 ACM/SaaS 검증이 계속 실패한다
  • VPC 내부에서는 되는데 인터넷에서는 안 된다(또는 반대)

이 중 하나면, 아래 체크리스트로 바로 들어가면 됩니다.

1. 정답부터: NS 위임의 “정상 상태” 정의(30초)

서브도메인 sub.example.com을 별도 호스티드 존으로 운영할 때 정상 상태는 아래 두 가지가 모두 만족되는 것입니다.

  1. Route 53에 sub.example.com Public Hosted Zone이 존재한다.

  2. 부모 존 example.com에 sub.example.com에 대한 NS 레코드가 있고, 그 값이 1)의 Hosted Zone이 제공하는 NS 4개와 완전히 동일하다.

여기서 “완전히 동일”은 다음을 포함합니다.

  • NS 값 4개가 정확히 일치(오타/누락/다른 존의 NS 혼입 금지)
  • 레코드 이름이 sub 또는 sub.example.com으로 올바르게 들어감(콘솔 UI에 따라 상대/절대 표기가 다름)

2. 7분 해결 체크리스트

2-1. 서브도메인 Hosted Zone이 “Public”인지 확인(1분)

Route 53에는 Hosted Zone이 두 종류가 있습니다.

  • Public Hosted Zone: 인터넷 DNS 질의에 응답
  • Private Hosted Zone: VPC 내부에서만 응답

가장 흔한 실수는 서브도메인 존을 Private으로 만들고, 부모 존에는 NS 위임을 걸어버리는 것입니다. 그러면 인터넷에서는 절대 해당 NS로 권한 위임이 성립하지 않습니다.

확인 방법

  • Route 53 콘솔에서 sub.example.com Hosted Zone 상세에 Type: Public hosted zone인지 확인

만약 Private이라면

  • Public Hosted Zone을 새로 만들고(이름 동일 가능), 그 Public Zone의 NS를 부모 존 NS 레코드에 넣어야 합니다.

2-2. 부모 존 NS 레코드가 “정확히 그 존”을 가리키는지 확인(2분)

서브도메인 Hosted Zone을 만들면 Route 53이 네임서버 4개를 제공합니다(예: ns-123.awsdns-45.net. 같은 형태).

해야 할 일은 단 하나입니다.

  • 부모 존 example.com에 sub.example.com에 대한 NS 레코드를 만들고
  • 값에 위 4개를 그대로 넣는다

하지만 운영 중에는 이런 실수가 자주 납니다.

  • 예전에 만들었던 다른 sub.example.com Hosted Zone의 NS를 넣음(삭제/재생성하면서 NS가 바뀜)
  • 값 4개 중 1~2개만 넣음
  • ns-... 끝의 점(.) 유무로 도구마다 표기가 달라 혼동(대부분은 자동 처리하지만, 복사/붙여넣기 중 오타가 생김)

검증은 콘솔보다 dig가 빠릅니다.

# 부모 존에서 sub에 대해 어떤 NS를 내보내는지 확인
# (권한 있는 응답이 아니어도, 현재 공개 DNS가 보는 위임 상태를 확인 가능)
dig sub.example.com NS +short

그리고 Route 53 서브도메인 Hosted Zone의 NS와 비교합니다.

# Route 53 콘솔에서 확인한 NS 목록을 파일/메모로 두고 비교
# 예: ns-123.awsdns-45.net.
#     ns-234.awsdns-56.com.
#     ns-345.awsdns-67.co.uk.
#     ns-456.awsdns-78.org.

불일치하면 해결은 즉시입니다.

  • 부모 존의 NS 레코드를 수정해서 서브도메인 Hosted Zone NS 4개로 교체

2-3. +trace로 “어디서 잘못 위임되는지” 한 번에 찾기(1분)

dig +trace는 루트부터 따라가며 위임 체인을 보여줍니다. NS 위임 오류는 이 명령 한 번으로 대부분 위치가 드러납니다.

dig +trace sub.example.com NS

관찰 포인트

  • example.com 단계에서 내려주는 NS가 Route 53 NS 4개인지
  • 중간에 다른 DNS 사업자(NS)로 위임되거나, 예전 레코드가 남아 있는지

만약 example.com 자체가 Route 53이 아니라면(예: 가비아/Cloudflare 등)

  • NS 위임 레코드는 부모 존을 실제로 호스팅하는 DNS 사업자에 넣어야 합니다.
  • Route 53 콘솔에 부모 존이 있다고 해서, 그게 실제 authoritative라는 보장은 없습니다.

2-4. 동일 서브도메인에 “중복 위임”이 있는지 확인(1분)

다음 케이스가 은근히 많습니다.

  • sub.example.com에 NS 위임을 걸어놓고
  • 동시에 sub.example.com에 A/AAAA/CNAME 레코드도 부모 존에 같이 존재

DNS 규칙상 NS 위임이 있으면 그 하위는 위임된 존이 권한(authoritative)을 갖는 게 일반적입니다. 하지만 레코드가 섞여 있으면, 운영자 입장에서는 “어떤 쿼리는 되고 어떤 쿼리는 안 되는” 상태로 보일 수 있습니다.

정리 원칙

  • sub.example.com을 별도 존으로 운영하기로 했다면, 부모 존에는 보통 NS 레코드만 남기고 나머지 sub.* 레코드는 서브도메인 Hosted Zone으로 옮기는 편이 안전합니다.

확인 명령

# 부모 존 관점에서 sub에 어떤 타입들이 걸려 있는지 점검
# (실제 레코드 조회는 콘솔이 빠르지만, 외부에서 보이는 현상은 dig로 확인)
dig sub.example.com A

dig sub.example.com CNAME

dig sub.example.com TXT

2-5. 캐시/전파 문제를 “오류”로 착각하지 않기(1분)

NS 레코드를 수정한 직후에는, 로컬/회사 DNS 리졸버가 이전 값을 캐시하고 있을 수 있습니다.

빠른 확인 방법

  • 서로 다른 리졸버로 질의해 결과가 다른지 확인
# Google Public DNS

dig @8.8.8.8 sub.example.com NS +short

# Cloudflare DNS

dig @1.1.1.1 sub.example.com NS +short

둘 중 하나는 바뀌었고 하나는 안 바뀌었다면, “설정 오류”가 아니라 “전파/캐시”일 가능성이 큽니다.

추가 팁

  • 부모 존의 NS 레코드 TTL이 너무 길면(예: 86400) 변경 반영이 오래 걸립니다.
  • 변경이 잦은 환경이라면 NS 레코드 TTL을 운영 정책에 맞게 조정하세요.

3. 실전 시나리오: Route 53에 서브도메인 위임 구성(정상 예시)

예시 목표

  • example.com은 기존 DNS(또는 Route 53)에서 운영
  • api.example.com만 Route 53 Public Hosted Zone으로 분리

3-1. Route 53에 api.example.com Public Hosted Zone 생성

생성 후 NS 4개를 확인합니다.

  • ns-111.awsdns-22.net.
  • ns-222.awsdns-33.com.
  • ns-333.awsdns-44.co.uk.
  • ns-444.awsdns-55.org.

3-2. 부모 존에 NS 레코드 추가

부모 존(example.com)에 아래 레코드를 추가합니다.

  • Name: api (UI에 따라 api.example.com으로 입력)
  • Type: NS
  • Value: 위 4개

3-3. 검증

# 위임이 정상인지 확인

dig api.example.com NS +short

# 권한 서버까지 따라가서 확인

dig +trace api.example.com NS

정상이라면 +trace 결과에서 example.com이 api.example.com에 대해 Route 53 NS로 위임하는 흐름이 보입니다.

4. 자주 나오는 “함정” 모음

4-1. Hosted Zone을 삭제했다가 다시 만들면 NS가 바뀐다

Route 53 Hosted Zone을 재생성하면 NS 세트가 바뀝니다. 이때 부모 존 NS를 업데이트하지 않으면, 위임은 즉시 깨집니다.

운영 팁

  • Hosted Zone 삭제/재생성은 최후의 수단으로 두고
  • 불가피하다면 변경 직후 부모 존 NS 레코드부터 갱신하세요.

4-2. 도메인 등록기관(Registrar) NS와 “서브도메인 위임”은 다른 층위다

  • 등록기관 NS는 example.com의 권한 DNS가 어디인지 지정
  • 서브도메인 NS 위임은 example.com 존 내부에서 sub.example.com의 권한 DNS를 지정

즉, 서브도메인 위임 문제인데 등록기관 설정만 만지면 해결이 안 됩니다(물론 부모 존 자체가 잘못 호스팅되고 있으면 예외).

4-3. Route 53 Resolver(인바운드/아웃바운드)와 혼동

VPC 내부 DNS 통합을 하다 보면 Route 53 Resolver 엔드포인트와 Hosted Zone을 섞어 생각하기 쉽습니다. 하지만 서브도메인 NS 위임은 기본적으로 Public DNS 권한 위임 문제이며, Resolver는 별개의 레이어입니다.

5. 운영 관점 체크: 변경 작업을 안전하게 만드는 방법

DNS 위임은 “작업 자체는 단순하지만, 영향 범위가 넓고 롤백이 까다로운” 변경입니다. 배포/권한/네트워크 이슈를 빠르게 줄이는 접근은 다른 장애 대응과도 유사합니다. 예를 들어 권한 설정 미스로 배포가 막힐 때는 Argo CD Sync 실패? AppProject RBAC로 해결하기처럼 원인 범주를 먼저 나누고 최소 변경으로 검증하는 방식이 효과적입니다.

또한 CI에서 AWS 권한 문제로 AssumeRole이 실패하면 배포 파이프라인 전체가 멈추는데, 이때도 체크리스트 기반으로 빠르게 진단합니다. 관련해서는 GitHub Actions OIDC로 AWS AssumeRoleAccessDenied 해결를 함께 참고하면, “권한/신뢰 정책/주체”를 분리해서 보는 관점이 DNS 운영에도 도움이 됩니다.

6. 7분 요약(그대로 따라 하기)

  1. sub.example.com Hosted Zone이 Public인지 확인
  2. 서브도메인 Hosted Zone의 NS 4개를 복사
  3. 부모 존에 sub.example.com NS 레코드가 있고 값이 완전히 동일한지 확인
  4. dig +trace sub.example.com NS로 위임 체인이 어디서 틀어지는지 확인
  5. 서로 다른 리졸버(@1.1.1.1, @8.8.8.8)로 캐시/전파인지 확인

여기까지 했는데도 해결이 안 되면, 대부분은 “부모 존이 실제로는 다른 DNS에서 권한을 가지고 있다”거나 “서브도메인 이름을 잘못 위임했다(오타/다른 레벨)” 같은 구조적 문제입니다. 이때는 +trace 출력에서 example.com 권한 NS가 어디인지부터 다시 확정하고, 그 DNS에 NS 위임 레코드를 넣는 것으로 되돌아가면 됩니다.

Discuss on Twitter • View on GitHub