DNS CNAME 레코드란: alias와 canonical name, 설정 제약

DNS의 CNAME 레코드는 별칭 이름(alias)을 다른 도메인 이름인 canonical name에 연결한다. CNAME의 왼쪽 이름이 별칭이고, 레코드 값으로 적힌 오른쪽 이름이 canonical name이다.

흔히 “CNAME은 도메인 별칭”이라고 줄여 말하지만, IP 주소를 직접 가리키거나 웹 주소를 다른 URL로 리다이렉트하는 기능은 아니다. 이 경계를 알아야 DNS 설정과 HTTP 동작을 섞지 않는다.

CNAME의 owner가 alias다

다음 레코드를 보자.

docs.example.com.  300  IN  CNAME  service.example.net.

• docs.example.com.: CNAME 레코드의 owner이자 alias
• service.example.net.: canonical name
• 300: 캐시에 보관할 수 있는 TTL

클라이언트가 docs.example.com의 A 레코드를 찾으면 DNS 해석 과정에서 CNAME을 만나 service.example.net의 주소를 다시 찾는다.

service.example.net.  300  IN  A  192.0.2.20

최종 결과에는 CNAME과 대상 이름의 A 레코드가 함께 보일 수 있다. 대상은 IP 주소가 아니라 DNS 이름이어야 한다.

CNAME은 HTTP 리다이렉트가 아니다

CNAME을 설정해도 브라우저 주소창의 URL은 자동으로 바뀌지 않는다. DNS는 접속할 IP 주소를 찾는 단계만 돕는다. 그 뒤 서버는 원래 요청의 호스트 이름에 맞는 가상 호스트와 TLS 인증서를 제공해야 한다.

예를 들어 old.example.com을 new.example.net의 CNAME으로 만들었다고 하자.

• DNS 질의는 new.example.net의 주소까지 따라갈 수 있다.
• 브라우저는 여전히 https://old.example.com/...에 접속한다고 생각한다.
• 서버 인증서에 old.example.com이 없거나 해당 호스트 설정이 없으면 HTTPS 오류나 잘못된 응답이 날 수 있다.
• 주소창까지 new.example.net으로 바꾸려면 웹 서버나 CDN에서 301·308 같은 HTTP 리다이렉트를 따로 설정해야 한다.

따라서 기존 글의 “이전 도메인 링크가 새 도메인으로 자동 전환된다”는 설명은 DNS 해석과 HTTP 이동을 구분하도록 고쳤다.

CNAME owner에는 다른 일반 레코드를 함께 둘 수 없다

RFC 2181은 하나의 DNS 이름에 CNAME이 있으면 그 이름에 다른 일반 데이터가 함께 존재할 수 없다고 설명한다. DNSSEC 관련 레코드에는 별도 규칙이 있지만, A·AAAA·MX·TXT 등을 CNAME과 같은 owner에 섞는 구성은 피해야 한다.

# 잘못된 구성 예
docs.example.com.  300  IN  CNAME  service.example.net.
docs.example.com.  300  IN  TXT    "verification=value"

이 제약 때문에 zone apex인 example.com에는 표준 CNAME을 놓기 어렵다. apex에는 이미 SOA와 NS 레코드가 필요하기 때문이다. 일부 DNS 제공자가 ALIAS·ANAME·CNAME flattening 같은 기능을 제공하지만 이는 표준 CNAME 레코드와 동일한 동작이 아니다. 실제 권한 응답에 어떤 레코드가 반환되는지는 제공자 문서와 dig로 확인해야 한다.

조회할 때는 CNAME과 최종 주소를 따로 본다

CNAME 자체는 다음처럼 확인한다.

dig docs.example.com CNAME

최종 주소까지 보고 싶다면 A와 AAAA 질의를 나눈다.

dig docs.example.com A
dig docs.example.com AAAA

+short는 빠르게 값을 볼 때 편하지만, 장애 분석에서는 전체 응답의 상태 코드와 TTL, Answer·Authority 섹션을 함께 보는 편이 낫다.

dig +short docs.example.com CNAME

결과를 읽을 때는 다음을 확인한다.

1. alias와 canonical name의 방향을 거꾸로 쓰지 않았는가?
2. CNAME 대상 이름에 최종 A·AAAA가 존재하는가?
3. CNAME이 자기 자신이나 순환하는 다른 별칭을 가리키지 않는가?
4. 같은 owner에 TXT·MX 같은 다른 레코드를 함께 두지 않았는가?
5. 웹 서비스라면 원래 호스트 이름의 TLS 인증서와 서버 설정이 준비됐는가?

A·AAAA·MX·NS·TXT와 함께 비교하려면 DNS 레코드 종류와 읽는 법, 리졸버가 CNAME을 따라가는 전체 맥락은 DNS 조회 과정에서 이어서 볼 수 있다.

이 글의 zone 데이터는 문법 설명을 위한 예약 예시 도메인이다. 실제 DNS 제공자에 레코드를 생성하거나 HTTPS 연결까지 시험한 결과를 의미하지 않는다.

참고 자료

• RFC 1034: Domain Names — Concepts and Facilities
• RFC 1035: Domain Names — Implementation and Specification
• RFC 2181: Clarifications to the DNS Specification