DNS와 레코드

2025. 4. 15. 19:19·Infra

상황

가비아에서 도메인을 구매한 당시에는 구매한 도메인에 A타입 레코드로 EC2 배포환경에 연결하였다.

 

하지만, 프론트의 배포환경을 AWS S3에서 CloudFlare 로 옮기고 그거에 따라 DNS 관리도 CloudFlare로 옮기게 되었는데

 

이 과정에서 기존에 가비아에 가비아 네임서버로 등록되어있는 상태를 CloudFlare 네임서버를 등록하는것으로 교체하였다.

가비아 에서 CloudFlare로 옮기면서 문득 1. 네임서버는 왜 바꿔야하는지, 2. 레코드는 어떤건지 궁금해서 파헤쳐본 내용을 이 글에서 기술한다.

 

네임서버

흔히 DNS라고 부르는건 사실 Domain Name System의 약자로 하나의 체계를 뜻한다.

실제로 도메인을 IP로 바꾸거나 혹은 다른 도메인으로의 요청으로 바꾸는 등의 역할을 수행하는것은 네임서버라고 한다.

그래서 네임서버는 흔히 해당 도메인을 관리하는 테이블이 존재한다.

 

그러한 네임서버는 계층적으로 구조가 되어있으며 크게

  1. 루트 네임서버
  2. TLD 네임서버
  3. 책임 네임서버
  4. 서브 도메인

등이 존재하게 된다.

 

그래서 재귀적 질의 혹은 반복적 질의 를 통해 최종적으로 주소를 얻게된다.

 

예를들어 

www.naver.com  이라는 주소가 있다면  

사실 젤뒤에 (.) 이 붙어있어서 (.) 이 루트 네임서버가 된다.

루트 네임서버에 가서 com를 관리하는 네임서버를 통해 com. 의 주소를 얻고

com에가서 naver.com를 관리하는 네임서버(예시: ns1.naver.com)를 통해 naver.com의 주소를 얻고

naver.com에서 www.naver.com을   알게된다.

 

결국 우리가 흔히 도메인을 산다고 하면, 책임 네임서버를 구매하는것일 가능성이 크다.

 

그래서 왜 네임서버 주소를 옮겨야 했는가?

사실 위에서 답이 나와있다.

내가 구매한 도메인이 가비아에서 xxx.com 이라고했을 때,

가비아에 돌아가고있는 네임서버가 있을 것이고,

xxx.com 뿐만아니라 다양한 가비아 내 관리하고있는 도메인들은 가비아 네임서버에 등록되어 있을 것이다.

 

따라서 xxx.com을 요청하면

루트 네임서버 -> TLD 네임서버 -> 가비아 네임서버 -> xxx.com에 등록된 IP주소 확인

이라는 흐름으로 진행될 것이다

 

CloudFlare의 DNS 체계를 사용하기 위해서는

CloudFlare에 도메인을 등록하고, 해당 도메인으로의 접근이 가비아 네임서버를 통하지 않아야 한다.

이 때문에, 가비아에서 도메인에 대한 네임서버 목록에 CloudFlare 네임서버 도메인을 기입하는 것이다.

출처: https://customer.gabia.com/manual/domain/286/991

 

 

정상적으로 처리되었다면 이제

루트 네임서버 -> TLD 네임서버 -> CloudFlare 네임서버 -> xxx.com에 등록된 IP 주소 확인 

이라는 흐름으로 진행될 것이다.


레코드

흔히 가비아나 CloudFlare에 대시보드로 가면 도메인에 대해서 IP주소를 매핑할 수도 있고 또 다른 도메인으로 연결할 수도 있다.

이러한 종류별로 나눈 것이 레코드 라고 한다.

출처: https://majjangjjang.tistory.com/159

 

흔히 보거나 사용할 수 있는 것들은 A, AAAA, CNAME, MX, NS 정도이다.

그런데, CloudFlare를 사용해서 도메인과 내가 원하는 애플리케이션 서버의 주소와 연결하려고 레코드를 설정할 때

내가 구매한 도메인에는 CNAME 타입을 사용할 수 없다고 한다.

그 이유가 뭘까?

 

왜 CNAME이 불가한 도메인이 있는가?

아까 질의 방식을 살펴보자면, 

xxx.com. 에 대해서 com. 에서 xxx.com. 에 대한 주소를 모른다면, 저걸 관리하는 네임서버를 가야 할 것이다.

따라서 기본적으로 xxx.com에 대한 레코드는 NS타입으로 최소한 하나의 레코드는 존재하는 것이다.

 

그런데 CNAME은 특별하게도 해당 도메인의 다른 레코드설정을 모조리 무시하게 된다.

출처: https://datatracker.ietf.org/doc/html/rfc1912#section-2.4

 

RFC 1912: Common DNS Operational and Configuration Errors

This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo provides information for the Internet community. This memo does not specify an Internet standard of

datatracker.ietf.org

그러면 만약에 CNAME 설정을 강제로 할 수 있다면 어떻게 될까?

 

com에서 xxx.com의 주소를 모르기에 NS 타입 레코드를 통해 네임서버를 사용해야 하는데,

CNAME으로 인해 NS 타입 레코드도 작동하지 않게 되어, 영원히 xxx.com의 주소를 모르게 될 것이다.

 

따라서 대부분의 DNS 제공업체에서는 구매한 도메인에 대해서 CNAME을 설정하지 못하게 막아놨을 것이다.

 

그래서 A레코드를 구매한 도메인에 설정하고, 서브도메인의 경우 CNAME으로 설정이 가능하게 된다.

'Infra' 카테고리의 다른 글

Nginx - 웹 서버와 WAS  (0) 2024.02.21
Jenkins 는 뭘까요  (0) 2024.01.16
'Infra' 카테고리의 다른 글
  • Nginx - 웹 서버와 WAS
  • Jenkins 는 뭘까요
devKhc
devKhc
  • devKhc
    개발저장소 by 회창
    devKhc
  • 전체
    오늘
    어제
    • 분류 전체보기 (24)
      • Web-Spring (7)
      • CS (5)
      • Infra (3)
      • DB (1)
      • Java (3)
      • CodeTree (5)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    Nginx #proxy #리버스 프록시
    samesite=none
    springboot #jenkins #CI/CD #Docker #EC2
    코딩테스트
    Multi-Processor
    SpringBoot
    코드트리조별과제
    이중모드와 다중모드
    운영체제
    set-cookie
    코드트리
    Springsecurity
    인터럽트 #운영체제 #공룡책
    인터럽트
    다중 코어 시스템
    JsonTypeInfo
    defaultoauth2authorizationrequestresolver
    JsonSubTypes
    모드비트
    try with resources
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
devKhc
DNS와 레코드
상단으로

티스토리툴바