lander.log

DNS 개념 정리 - Authority와 Name Scope

7 min read

DNS 개념 정리 - Authority와 Name Scope

Route 53, ACM, 도메인 연결 작업에서 반복되는 혼란을 Authority(권한) 와 Name Scope(범위) 두 축으로 정리한다.

Route 53 Hosted Zone 생성, ACM 인증서 발급, 도메인 연결 작업을 하다 보면 다음과 같은 혼란에 빠진다.

  • “Hosted Zone을 *.example.com으로 만들어야 할까, example.com으로 만들어야 할까?”
  • “ACM에서 *.example.com 인증서를 받았는데, 왜 example.com은 접속이 안 될까?”
  • “DNS 검증용 CNAME은 도메인 등록기관에 넣어야 할까, Route 53에 넣어야 할까?”

이 질문들은 DNS의 두 가지 핵심 원리 — Authority와 Name Scope — 가 분리되지 않아서 발생한다.

핵심 개념

Authority (권한)

“이 도메인 영역(Zone)의 관리 책임이 누구에게 있는가?” 에 대한 이야기다.

위임(Delegation)과 SOA

DNS는 하나의 거대한 데이터베이스가 아니라 분산된 시스템이다. 상위 도메인(Parent Zone)은 하위 도메인(Child Zone)에게 관리 권한을 넘겨주는데, 이를 위임(Delegation) 이라 한다.

  1. NS 레코드 (Name Server): 상위 도메인(예: .com)이 “이제부터 example.com의 관리는 이 네임서버들이 담당한다”라고 가리키는 손가락이다.
  2. SOA 레코드 (Start of Authority): 위임받은 네임서버(예: Route 53)가 “내가 여기서부터의 진짜 관리자다”라고 선언하는 문서다.

권한의 흐름

graph TD
    Root["Root (.)"] -->|Delegation| Com[".com TLD Server"]
    Com -->|NS Record| R53["Route 53 (example.com)"]

    subgraph "Authority Boundary"
    R53 -->|Authoritative Answer| Rec[A Record: www\.example\.com]
    R53 -->|Authoritative Answer| CNAME[CNAME: _acm-validation...]
    end

    Registrar["GoDaddy/Gabia"] -.->|Register NS| Com

CNAME 검증은 어디에?

“DNS 검증 CNAME을 어디에 넣어야 하는가?”의 답은 현재 Authority를 가진 곳이다.

  • 도메인 등록기관의 기본 네임서버를 쓰고 있다면 → 등록기관 DNS 설정
  • Route 53으로 네임서버를 변경(NS 위임)했다면 → Route 53 Hosted Zone

Name Scope (이름 범위)

“이 규칙(*)이 어떤 호스트 이름들까지 적용되는가?” 에 대한 이야기다. 가장 큰 오해는 와일드카드(*)의 범위에서 발생한다.

와일드카드의 한계

RFC 표준은 와일드카드의 적용 범위를 단일 레벨(Single Level) 로 제한한다.

  1. DNS 와일드카드 (RFC 1034/4592): *.example.com은 a.example.com에는 응답하지만, a.b.example.com이나 example.com 자체(Apex Domain)에는 응답하지 않는다.
  2. 인증서 와일드카드 (RFC 6125): 인증서의 와일드카드도 가장 왼쪽의 단일 라벨에만 적용된다.

적용 범위

graph TD
    Root[example.com]
    Wild["*.example.com"]

    Root -->|Covered? NO| Apex["example.com (Root Domain)"]
    Wild -->|Covered? YES| Sub1["www\.example\.com"]
    Wild -->|Covered? YES| Sub2["api.example.com"]
    Wild -->|Covered? NO| Deep["dev.api.example.com"]

    style Apex fill:#ff9999
    style Sub1 fill:#99ff99
    style Sub2 fill:#99ff99
    style Deep fill:#ff9999

Hosted Zone과 인증서 이름

  • Hosted Zone 이름: *.example.com이 아니라 example.com 으로 만들어야 한다. Hosted Zone은 “영역(Zone)“을 정의하는 것이지, 특정 호스트를 정의하는 것이 아니다.
  • ACM 인증서: *.example.com 인증서는 example.com을 커버하지 않는다. 루트 도메인과 서브 도메인을 모두 쓰려면 example.com과 *.example.com 두 가지를 모두 인증서에 포함해야 한다.

실무 적용

DNS 문제를 해결할 때 다음의 의사결정 트리를 따르면 효율적이다.

  1. 설정 위치 결정 (Authority): dig NS example.com을 조회하여 나오는 네임서버가 내가 설정하려는 곳(Route 53 등)과 일치하는지 확인한다. 일치하지 않는다면 엉뚱한 곳에 레코드를 만들고 있는 것이다.
  2. 적용 범위 확인 (Name Scope): 와일드카드는 바로 아래 단계만 커버한다. 2단계 서브도메인(a.b.example.com)이 필요하다면 별도의 와일드카드(*.b.example.com)나 명시적 레코드가 필요하다.

Trade-off: 와일드카드(*) 사용은 설정 편의성을 높여주지만, 의도치 않은 서브도메인까지 노출될 보안 위험이 있다. 운영 환경에서는 가능한 명시적 FQDN을 사용하는 것이 권장된다.

요약

DNS 설정이 혼란스러울 때는 두 가지 질문으로 상황을 정리한다.

  1. Authority: “지금 내가 수정하려는 곳이 이 도메인의 Authoritative NS인가?”
  2. Name Scope: “내가 설정한 와일드카드가 Apex(example.com)이나 손자(a.b.example.com)까지 커버한다고 착각하고 있지 않은가?”

이 프레임워크를 통해 “연결이 안 돼요”라는 막연한 문제에서 “Authority가 위임되지 않았다”거나 “Name Scope가 닿지 않는다”와 같이 정확한 원인을 진단할 수 있다.

참고 자료

Recent Posts

See 16 more →