CNAME 레코드: 도메인의 별칭

CNAME 레코드가 하는 말은 이것입니다: "저는 IP 주소가 없어요. 저쪽에 물어보세요."

이게 전부입니다. www.example.com을 조회했을 때 CNAME이 example.com을 가리키고 있다면, DNS는 그 포인터를 따라가 정식 이름(canonical name)에게 실제 답을 묻습니다. 리졸버는 실제 IP 주소를 찾을 때까지 계속 따라갑니다.

www.example.com.    IN    CNAME    example.com.
blog.example.com.   IN    CNAME    hosting.platform.com.
cdn.example.com.    IN    CNAME    cdn.provider.net.

첫 번째 필드는 별칭(누군가가 조회한 이름)입니다. 마지막 필드는 정식 이름(실제 답을 찾을 수 있는 곳)입니다.

CNAME은 단순히 다른 이름을 가리키는 것이 아닙니다—제어권을 위임하는 것입니다. "저는 이 답을 관리하지 않아요. 저쪽이 관리해요."라고 말하는 것입니다.

CNAME이 중요한 이유

WWW 문제: www.example.com을 example.com으로 가리킵니다. 서버의 IP가 바뀌면 A 레코드 하나만 업데이트하면 됩니다. CNAME은 자동으로 따라갑니다.

CDN: cdn.example.com이 customer123.cdn-provider.net을 가리키도록 만듭니다. CDN 제공업체가 자신의 인프라를 관리합니다—성능이나 장애 복구를 위해 다른 서버로 트래픽을 라우팅해야 할 때 그쪽에서 DNS를 업데이트합니다. 제어권을 위임했기 때문에 여러분의 CNAME은 계속 작동합니다.

SaaS 통합: 헬프데스크 시스템, 이커머스 플랫폼, 기타 서비스들은 support.example.com이 customer-name.helpdesk-service.com을 가리키는 CNAME을 만들어달라고 요청합니다. 여러분은 브랜드 URL을 얻고, 그쪽에서 인프라를 관리합니다.

환경 관리: 애플리케이션 코드를 변경하지 않고 staging.example.com이 다른 서버를 가리키도록 합니다. 스테이징이 새 인프라로 이전되면 CNAME 대상을 업데이트하면 됩니다.

존 정점 문제

example.com 자체에는 CNAME을 만들 수 없습니다—www.example.com과 같은 서브도메인에만 만들 수 있습니다.

이것은 임의적인 규칙이 아닙니다. 두 가지 DNS 규칙이 충돌합니다:

1. 존 정점에는 반드시 SOA(권한 시작)와 NS(네임 서버) 레코드가 있어야 합니다
2. CNAME이 있는 이름에는 다른 레코드가 있어서는 안 됩니다

두 규칙 모두 이유가 있습니다. SOA와 NS 레코드는 존이 작동하기 위해 필수입니다. 그리고 CNAME이 존재하면 리졸버가 반드시 따라가야 하는데—그 이름에 다른 레코드가 있으면 어떤 것이 진짜 답인지 모호해집니다.

결과적으로: 존 정점에는 여러 레코드 유형이 필요하므로 CNAME은 허용되지 않습니다.

실질적인 문제: example.com과 www.example.com 모두 CDN으로 연결하고 싶지만, CDN은 CNAME을 요구하고 존 정점에는 CNAME을 만들 수 없습니다.

해결 방법

ALIAS/ANAME 레코드: 일부 DNS 제공업체는 존 정점에서 CNAME처럼 동작하지만 조회 시 A 레코드를 반환하는 독자적인 레코드 유형을 제공합니다. Cloudflare는 이를 "CNAME 평탄화"라고 부릅니다. Route 53은 "Alias 레코드"라고 부릅니다. 표준화되지 않았기 때문에 제공업체마다 지원 여부가 다릅니다.

다중 A 레코드: 존 정점과 www 모두 IP 주소로 직접 가리킵니다. IP가 변경되면 둘 다 업데이트해야 합니다. 어디서나 작동합니다.

HTTP 리다이렉트: 존 정점을 브라우저를 www.example.com으로 보내는 간단한 리다이렉트 서버로 가리킵니다. www 서브도메인에는 CNAME을 사용합니다. 리다이렉트 단계가 추가되지만 안정적으로 작동합니다.

연쇄 조회

CNAME은 다른 CNAME을 가리킬 수 있습니다:

app.example.com.        IN    CNAME    service.company.com.
service.company.com.    IN    CNAME    lb.hosting.net.
lb.hosting.net.         IN    A        203.0.113.10

리졸버는 IP 주소를 찾을 때까지 각 포인터를 따라갑니다. 하나의 답을 위해 세 번의 조회가 필요합니다.

성능 비용

체인의 각 CNAME은 잠재적으로 추가 DNS 쿼리를 필요로 합니다. 각 쿼리에 50ms가 걸린다면, 2단계 체인은 브라우저가 연결을 시작하기도 전에 100ms가 추가됩니다.

CNAME TTL이 문제를 더 복잡하게 만듭니다. CNAME 자체에는 최종 A 레코드와 별도의 TTL이 있습니다. TTL이 일치하지 않으면 오래된 캐싱이나 불필요한 재조회가 발생할 수 있습니다.

체인을 짧게 유지하세요: 최대 1~2단계. 체인이 길수록 지연이 쌓이고 장애 지점이 늘어납니다. 성능이 중요할 때는 직접 A 레코드가 유리하지만—CNAME을 유용하게 만드는 위임의 이점을 잃게 됩니다.

CNAME 레코드에 관해 자주 묻는 질문

루트 도메인에 CNAME을 사용할 수 있나요?

아니요. 존 정점(example.com, 서브도메인 없음)에는 CNAME 레코드를 사용할 수 없습니다. 존 정점에는 SOA와 NS 레코드가 있어야 하는데, 이 레코드들은 CNAME과 공존할 수 없습니다. DNS 제공업체가 지원한다면 ALIAS/ANAME 레코드를 사용하거나, A 레코드로 존 정점을 직접 IP 주소로 가리키세요.

CNAME 대상이 다운되면 어떻게 되나요?

별칭도 함께 실패합니다. www.example.com이 hosting.provider.com을 가리키고 있는데 그 제공업체의 DNS가 응답을 멈추면, 여러분의 도메인 조회도 실패합니다. 체인에 있는 모든 도메인의 가용성에 의존하게 됩니다—이것이 위임의 대가입니다.

CNAME TTL은 얼마로 설정해야 하나요?

유연성과 성능의 균형을 맞추세요. 짧은 TTL(300~3600초)은 대상을 빠르게 변경할 수 있지만 DNS 쿼리 부하가 늘어납니다. 긴 TTL(86400초)은 쿼리를 줄이지만 변경 사항이 전파되는 데 시간이 걸립니다. 대상을 얼마나 자주 변경할 것인지에 맞춰 TTL을 설정하세요.

CNAME이 IP 주소를 가리킬 수 있나요?

아니요. CNAME은 IP 주소가 아닌 도메인 이름을 가리켜야 합니다. IP로 직접 가리키고 싶다면 A 레코드(IPv4의 경우) 또는 AAAA 레코드(IPv6의 경우)를 사용하세요.

CNAME 평탄화를 지원하는 DNS 제공업체는 어디인가요?

지원하는 주요 제공업체로는 Cloudflare(CNAME 평탄화), Amazon Route 53(Alias 레코드), Azure DNS(alias 레코드), DNS Made Easy(ANAME), Namecheap(ALIAS), DNSimple(ALIAS), Name.com(ANAME)이 있습니다. 많은 소규모 레지스트라와 공유 호스팅 패널은 이 기능을 지원하지 않습니다.