lander.log

DNS Authority and Name Scope

4 min read

DNS Authority and Name Scope

정의 (Definition)

DNS/Route 53/ACM 실무에서 반복되는 혼동을 Authority(누가 최종 정답을 제공하는가) 와 Name Scope(어디까지 적용되는가) 라는 두 축으로 분해해, “어디에 무엇을 설정해야 효력이 생기는지”를 빠르게 판단하기 위한 프레임워크입니다.

문제가 되는 배경 (Problem Context)

DNS 문제의 상당수는 다음 두 질문 중 하나를 틀려서 발생합니다.

  • Authority: “어디에 등록해야 반영되는가?”
  • Scope: “이 설정/인증서가 정확히 어디까지 커버하는가?”

핵심 메커니즘 (How it Works)

축질문관련 요소쉬운 예시
Authority(권한)누가 정답을 알고 책임지는가?NS Record, Hosted Zone“민원은 담당 기관에 넣어야 처리된다.”
Name Scope(범위)규칙이 어디까지 적용되는가?FQDN, Wildcard, SAN“와일드카드는 어디까지 포함되는가?”

불변 조건과 보장 범위 (Invariants & Guarantees)

  • 보장: Authority가 아닌 곳에 레코드를 넣으면, 의도한 DNS 응답에 영향을 주지 못합니다.
  • 보장: Name Scope를 오해하면(예: *.example.com), TLS/DNS 구성이 “부분적으로만” 적용되어 장애가 발생할 수 있습니다.
  • 비보장: 변경이 즉시 관측된다는 보장은 없습니다(TTL/캐시).

비유 (Analogy)

Authority는 “담당 기관(권한자)”, Scope는 “적용 범위(대상 집합)”입니다. 담당 기관이 맞아도 범위를 잘못 잡으면 문제는 그대로입니다.

실무적 함의 (Operational Implications)

  • DNS 검증(CNAME), 레코드 변경은 Authority가 있는 곳 에 해야 합니다.
  • 인증서는 “도메인 이름 집합(SAN)”의 문제이므로 Scope 관점에서 검증해야 합니다.

주의사항 / 오해 (Pitfalls & Misconceptions)

  • “도메인을 산 곳”이 항상 Authority인 것은 아닙니다.
  • *.runmile.co.kr이 runmile.co.kr을 커버한다고 가정하면, 배포 후 루트 도메인 TLS가 깨질 수 있습니다.

실전 시나리오 Q&A

Q1. ACM 인증서 발급 시 *.runmile.co.kr만 있으면 runmile.co.kr도 커버되나요?

A. 아니요.(Name Scope 관점)

  • 이유: 와일드카드는 보통 1단계 하위만 커버합니다.
  • 해결: SAN에 runmile.co.kr을 명시적으로 추가합니다.

Q2. ACM DNS 검증 CNAME은 어디에 등록해야 하나요?

A. 현재 도메인의 Authority가 있는 네임서버(Hosted Zone)에 등록해야 합니다.(Authority 관점)

  • 확인법: dig ns runmile.co.kr로 실제 NS를 확인합니다.

Q3. Route 53으로 이사(Migration) 갔는데 등록기관에도 레코드를 남겨둬야 하나요?

A. 아니요.(Authority 이동 관점)

  • NS가 Route 53을 가리키기 시작했다면, 이후 레코드는 Route 53에서 관리합니다.

References

Recent Posts