문제

어떤 플랫폼이 “something.theirservice.com을 가리키는 CNAME 레코드를 만드세요”라고 했고, DNS 관리 화면을 열었더니 아무것도 설명해 주지 않는 타입 드롭다운, 이름 칸, 값 칸이 있습니다. 타입을 잘못 고르거나 엉뚱한 칸에 엉뚱한 걸 넣으면 연결은 조용히 실패하고, 플랫폼 대시보드는 계속 “DNS 대기 중”이라고만 하고, 왜 그런지 알 길이 없습니다.

CNAME은 설명하기는 가장 쉬운데 미묘하게 틀리기도 가장 쉬운 레코드 타입입니다. 하는 일은 딱 하나 — 어떤 이름을 다른 이름의 별칭으로 만듭니다. www.example.com은 example.com의 CNAME입니다. shop.example.com은 mystore.myplatform.com의 CNAME입니다. 리졸버가 CNAME을 만나면 거기서 멈추고, 대상을 읽고, 그 대상에서 조회를 다시 시작합니다 — 실제 주소 레코드에 닿을 때까지 별칭을 따라갑니다.

“대상에서 다시 시작한다”는 이 동작이 핵심이고, 모두를 걸어 넘어뜨리는 두 규칙도 여기서 나옵니다.

CNAME이 가리키는 단 한 가지

CNAME의 값은 호스트 이름이지, IP 주소가 아닙니다. 여기서 사람들이 가장 먼저 틀립니다. 203.0.113.10에 서버가 있고, CNAME 옵션이 보이니, IP를 거기 붙여넣으려 합니다. 안 됩니다. CNAME은 “이 다른 이름에 대해 물어봐”라는 뜻인데, IP는 물어볼 이름이 아니기 때문입니다.

기준은 짧습니다:

  • 플랫폼이 준 호스트 이름이 있으면(cname.vercel-dns.com, yourname.github.io, d1a2b3.cloudfront.net, 로드밸런서 DNS 이름): CNAME, 값 = 그 호스트 이름.
  • 날것의 IP 주소가 있으면: A 레코드(IPv4) 또는 AAAA 레코드(IPv6), 값 = 그 주소.

플랫폼이 IP 대신 CNAME 대상을 주는 건 의도적입니다. 그들의 내부 주소는 예고 없이 바뀌는데, CNAME은 조회할 때마다 다시 해석해 그 변경을 자동으로 따라갑니다. 그들의 IP를 A 레코드에 박아두면, 그들이 주소를 바꾸는 날 내 사이트가 깨지고 아무도 알려주지 않습니다.

모두를 놀라게 하는 규칙: CNAME은 이름을 공유할 수 없다

“저장이 안 돼요”, “반만 돼요” 보고 대부분의 원인이 이 제약입니다. RFC 1034 §3.6.2는 CNAME이 있는 이름에는 다른 데이터가 없다고 규정합니다. CNAME과 같은 이름에는 어떤 종류의 두 번째 레코드도 둘 수 없습니다 — A도, MX도, TXT도, 또 다른 CNAME도.

이건 아주 평범하고 현실적인 방식으로 발목을 잡습니다:

  • example.com에 MX 레코드로 메일을 설정해 뒀는데, 그 이름을 웹 호스트로 CNAME하려 합니다. 안 됩니다 — MX와 CNAME은 같은 이름에 공존할 수 없습니다.
  • 어떤 서비스가 이미 CNAME인 서브도메인에 인증용 TXT 레코드를 추가하라고 합니다. 안 됩니다 — CNAME이 그 이름을 독점합니다.
  • 만일을 대비해 www에 CNAME과 A 레코드를 둘 다 두려 합니다. 안 됩니다 — 하나만 고르세요.

웹 대상과 같은 이름에 메일·TXT, 그 밖에 뭔가가 정말 필요하다면, 거기에는 CNAME 대신 A 레코드를 쓰거나(A 레코드에는 이 독점 규칙이 없습니다), CNAME하려던 서비스를 다른 라벨로 옮기세요.

루트 도메인이 다른 이유

apex — 앞에 아무것도 없는 맨 example.com — 에는 CNAME을 넣을 수 없습니다. apex는 SOA·NS 레코드를 반드시 가져야 하고(그게 apex를 존으로 만드는 것입니다), 위 규칙대로 CNAME은 그것들과 이름을 공유할 수 없습니다. 이건 제공업체 특이사항이 아니라 실제 제약입니다.

플랫폼이 “루트 도메인을 우리 쪽으로 CNAME하세요”라고 한다면, 실제로 필요한 건 DNS 제공업체의 ALIAS, ANAME, CNAME 플래트닝 기능입니다 — apex에서 CNAME처럼 동작하지만 뒤에서 진짜 A/AAAA 레코드로 해석돼 apex가 여전히 별칭이 아닌 주소 레코드를 갖게 하는 합성 레코드입니다. Cloudflare는 이 플래트닝을 자동으로 하고, Route 53은 alias 레코드, 다른 곳은 ANAME이라 부릅니다. 평범한 서브도메인에는 이 얘기가 전부 해당 없음 — 그냥 CNAME이 맞습니다.

이름 칸에 뭘 넣나

모든 DNS 관리 화면은 이름/호스트 칸에 입력한 값 뒤에 도메인을 자동으로 붙입니다. 그래서 www.example.com에는 이렇게만 넣습니다:

www

www.example.com이 아닙니다. 전체 이름을 다 쓰면 뒤에 존이 또 붙어 www.example.com.example.com 레코드가 되고, 이건 아무에게도 해석되지 않습니다. 조회를 해서 두 번 붙은 이름을 보기 전까지는 보이지 않습니다. 일부 화면은 “이건 완성된 이름이니 붙이지 마”라는 뜻으로 끝에 점을 원하고, Cloudflare는 전체 이름을 붙여넣으면 존을 떼어 줍니다 — 하지만 어디서나 안전한 습관은 라벨만 입력하기입니다.

체인과 루프

CNAME은 다른 CNAME을 가리킬 수 있고, 그게 또 다른 걸 가리킬 수 있습니다 — 리졸버가 체인을 따라갑니다. 합법이지만 홉마다 조회가 하나씩 늘고 깨질 지점도 하나씩 늘어나니 체인은 짧게 유지하세요. 절대 만들면 안 되는 건 루프입니다: a.example.com → b.example.com → a.example.com. 리졸버가 순환을 감지해 실패(SERVFAIL)를 반환하고, 두 이름 아래로는 아무것도 안 열립니다. 레코드를 “정리”한 뒤 어떤 이름이 갑자기 해석을 멈췄다면, 두 별칭이 서로를 가리키게 만들지 않았는지 확인하세요.

DechoNet으로 확인

  • DNS 조회는 이름을 해석하고 실제로 따라가는 CNAME 체인을 보여줍니다 — 별칭이 의도한 곳을 가리키는지 확인하고, 두 번 붙은 이름 함정(www.example.com.example.com이 답에 그대로 나옵니다)을 잡고, 대상 자체가 없다는 NXDOMAIN을 보는 가장 빠른 방법입니다.
  • DNS 전파는 전 세계 리졸버에서 한 번에 이름을 확인합니다. “이전 TTL만 기다리면 됨”(일부 리졸버는 보이고 일부는 아직)과 “레코드가 틀림”(아무도 못 봄)을 구분할 수 있습니다.

해결 체크리스트

  • 정말 CNAME이 맞는지 확인: IP가 아니라 호스트 이름을 받았다. (IP → A/AAAA로.)
  • 이름/호스트 칸에는 라벨만(www, shop), 절대 전체 www.example.com이 아니게.
  • 그 이름에 다른 레코드가 없게 — A·MX·TXT가 함께 있으면 안 됨. 필요하면 A 레코드로.
  • apex에는 두지 말 것: 맨 루트 도메인은 CNAME이 아니라 ALIAS/ANAME/플래트닝이 필요.
  • 저장 후 DNS 조회로 확인 — 답이 두 번 붙은 이름이나 NXDOMAIN이 아니라 내 대상인지.
  • 일부 리졸버만 보인다면, 올바른 레코드를 다시 고치지 말고 이전 TTL을 기다리며 전파를 확인하세요.

이럴 땐 넘기세요(에스컬레이션)

  • 대상이 NXDOMAIN이거나 주소 레코드가 없음. CNAME은 맞는데 해석되지 않는 이름을 가리키는 것 — 고칠 곳은 내가 아니라 플랫폼 쪽입니다. 그들이 준 정확한 대상 문자열을 확인하세요.
  • 같은 이름에 메일과 웹 별칭이 둘 다 필요. 한 이름에 MX와 CNAME을 함께 둘 수 없습니다. 웹 대상은 A 레코드를 쓰거나, 별칭 서비스를 다른 라벨로 옮기세요.
  • apex가 레코드를 안 받음. 제공업체에 ALIAS/ANAME/플래트닝 옵션이 없으면 루트는 별칭을 걸 수 없습니다 — 지원하는 DNS 제공업체로 옮기거나, apex는 A 레코드로 두고 www만 CNAME하세요.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.