CDN이든, 정적 호스팅이든, something.theirdomain.com에 사는 어떤 SaaS든 가입하면 안내가 하나 온다. “CNAME으로 저희 쪽을 가리키세요.” 좋다. 나는 example.com — 벌거벗은 도메인, 사람들이 실제로 타이핑하는 그것 — 이 저쪽 콘텐츠를 서빙하길 원한다. 그래서 DNS 패널을 열고 apex에 CNAME을 추가하려 하면, 제공업체가 대놓고 거부하거나 — 더 나쁘게는 — 받아들이고 조용히 이메일을 망가뜨린다.
DNS에서 가장 오래된 발등 찍기 중 하나인데, 여기 걸린 사람 대부분이 왜 금지인지 이해하지 못한다. 등록업체가 까다로워서가 아니다. 1987년에 나온 규칙이고, 단 한 번도 굽힌 적이 없다.
이 규칙은 웹보다 오래됐다
CNAME은 “canonical name”의 약자다 — “이 이름은 별칭이니, 저 다른 이름을 대신 찾아라”라고 말한다. DNS가 실제로 어떻게 작동하는지 정의한 문서 RFC 1034는 §3.6.2에 제약을 하나 박아 뒀다. 풀어 쓰면: 어떤 이름에 CNAME 레코드가 있으면, 그 이름엔 다른 어떤 레코드 타입도 있어선 안 된다. RFC 2181 §10.1은 나중에 이걸 한 문장으로 다시 못박았는데, 사람들이 계속 틀렸기 때문이다. “If a CNAME RR is present at a node, no other data should be present.”
논리는 깔끔하다. CNAME은 완전한 리다이렉트다. www.example.com이 cdn.provider.net으로의 CNAME이면, www.example.com에 대한 모든 쿼리 — A, AAAA, TXT, MX, 뭐든 — 가 그 별칭을 쫓게 돼 있다. www.example.com이 자기만의 MX 레코드도 갖는 여지는 없다. CNAME이 이미 “나는 진짜 이름이 아니야, 딴 데로 가”라고 말했으니까. 별칭과 로컬 데이터는 서로 모순되는 지시다. 그래서 스펙이 그 조합을 금지한다.
이제 apex — 앞에 아무것도 없는 example.com — 를 보자. apex는 선택적 공간이 아니다. 모든 존은 정의상 apex에 SOA 레코드(존의 시리얼 번호와 타이밍)와 NS 레코드(어느 네임서버가 권한을 갖는지)를 지닌다. 필수다. 그게 없는 존은 존이 아니다. RFC 1035가 요구하고, 애초에 example.com을 위임되고 호스팅되는 도메인으로 만들어 주는 게 바로 그것들이다.
그러니 apex엔 항상 다른 데이터 — 최소 SOA와 NS — 가 있다. 그리고 CNAME은 다른 데이터와 공존할 수 없다. 두 사실이 충돌하고, 충돌은 전면적이다: 스펙을 지키는 서버에선 apex에 CNAME을 절대 걸 수 없다. “권장하지 않음”이 아니다. 정의상 깨진 존을 만들지 않고선 구조적으로 불가능하다. 그걸 “허용해 주는” DNS 서버는 당신에게 거짓말을 하고 있거나, 당신의 NS 레코드를 곧 잡아먹으려는 참이다.
그래서 업계 전체가 편법을 썼다
이걸 그저 성가신 게 아니라 흥미롭게 만드는 대목이 여기다: 현대 웹은 DNS가 apex CNAME을 불가능하게 만든 바로 그 순간에 apex CNAME을 필요하게 만들었다.
CDN과 클라우드 로드밸런서는 안정적인 IP를 주지 않는다. 호스트명을 준다 — d1234.cloudfront.net, myapp.herokudns.com — 그리고 그 호스트명은 지금 이 순간 가장 건강하고 가까운 IP 집합으로 풀린다. 이름 뒤의 IP가 알리지 않고 바뀌는 게 요점의 전부다. apex에 오늘의 IP를 가리키는 A 레코드를 하드코딩하면 CDN을 무력화한 것이다: 내일 그 IP가 옮겨가면 사이트가 캄캄해진다. 당신은 apex에서 별칭 동작이 필요하다. 그런데 가질 수 없다.
그래서 DNS 제공업체들은 스펙을 우회하는 길을 발명했다. 이름은 다르지만 수법은 동일하다: flattening. apex CNAME처럼 보이는 뭔가를 설정한다 — Route 53은 Alias 레코드, DNSimple 등은 ANAME, Cloudflare는 CNAME Flattening이라 부른다. 권한 네임서버가, 클라이언트가 apex의 A 레코드를 물으면, 대상 호스트명을 스스로 조용히 풀어서 나온 IP 주소들을 마치 당신 apex에 놓인 평범한 A 레코드인 양 돌려준다. 클라이언트는 CNAME을 절대 보지 못한다. apex에 완벽히 합법인 A/AAAA 레코드를 본다. SOA와 NS는 제자리에 있다. 회선 위에선 아무것도 위반되지 않는다.
Cloudflare는 flattening을 무료로 제공하고 apex에 CNAME을 걸려 하면 자동으로 켠다. Route 53, DNSimple, NS1, Dyn, Bunny — 진지한 관리형 DNS 제공업체 대부분이 이제 어떤 형태로든 갖고 있다. 작동한다. 수백만 도메인이 이걸로 돌아간다.
설정 마법사가 아무도 언급하지 않는 대가도 있다. 당신의 네임서버가 클라이언트의 리졸버 대신 대상을 풀면, 지리적 스티어링이 깨진다. CDN은 쿼리가 어디서 오는지에 따라 다른 IP를 나눠준다 — 프랑크푸르트 사용자를 프랑크푸르트 엣지로 보내는 방식이 그거다. 그런데 flattening에선 CDN이 보는 쿼리가 사용자가 아니라 당신 DNS 제공업체의 리졸버에서 온다. 그래서 CDN은 당신 네임서버의 위치에 최적화하고, 모든 방문자는 그 위치에 가까운 엣지로 향한다. 작은 사이트에선 눈치도 못 챈다. 글로벌 사이트에선 first byte가 20ms냐 150ms냐의 차이이고, DNS는 완전히 정상으로 보이니 디버깅이 미칠 노릇이다. TTL 문제도 물려받는다: 합성된 A 레코드는 대상이 아니라 당신 제공업체가 고른 TTL을 갖는다. 그래서 빠르게 failover하는 오리진이 이미 죽은 주소에 핀 꽂힌 채로 당신 존이 계속 그걸 내주는 사태가 벌어질 수 있다.
참고로 ANAME은 진짜 표준이 될 뻔했다. IETF 드래프트 draft-ietf-dnsop-aname가 2017년부터 2019년까지 작업됐다. 4번째 리비전까지 갔다가 2020년 1월 RFC가 되지 못하고 만료됐다. 아이디어는 탄탄했다. 워킹그룹이 리졸버와 권한 서버가 해석 작업을 어떻게 나눌지 합의하지 못했고, 위원회에서 죽었다. 그러니 오늘 당신이 쓰는 모든 ANAME/ALIAS 구현은 이름만 공유하는 독자 확장이지 상호운용되는 표준이 아니다. 두 제공업체의 ANAME 레코드는 미묘하게 다르게 동작하고, 맞춰볼 대상 자체가 없으니 어느 쪽도 “옳지” 않다.
진짜 해결책은 존재한다. 당신 브라우저가 무시할 뿐.
2023년 IETF는 마침내 진짜 답을 냈다: RFC 9460, SVCB와 HTTPS 리소스 레코드. 그 안에 apex가 필요로 하던 바로 그 메커니즘이 묻혀 있다. 우선순위 0인 HTTPS 레코드가 스펙이 말하는 AliasMode다 — RFC 9460은 그 주된 목적이, 말 그대로, CNAME이 허용되지 않는 존 apex에서 별칭을 허용하는 것이라고 적는다. SOA·NS와 깔끔하게 공존하는 apex용 CNAME인데, CNAME처럼 이름 전체를 강탈하지 않고 특정 서비스(HTTPS)에만 말을 걸기 때문이다. 표준화됐고, 상호운용되고, apex에 안전하다. 서른 살짜리 문제가 서류상 해결됐다.
그리고 막상 쓰려고 가면 급소를 발견한다. 브라우저는 HTTPS 레코드를 쿼리한다 — Chrome, Firefox, Safari 모두 한다 — 그리고 거기서 ServiceMode 파라미터, 이를테면 서버가 말하는 ALPN 프로토콜이나 Encrypted Client Hello 키 같은 걸 기꺼이 읽는다. 그런데 AliasMode, 우선순위 0 레코드, apex 문제를 실제로 푸는 그것은? 실무에선 Apple 스택만 따른다. Chromium과 Firefox는 HTTPS 레코드를 읽고 나서 별칭을 쫓지 않는다 — AliasMode가 요구하는 후속 해석을 하지 않는다. 웹 트래픽의 압도적 다수를 나르는 두 엔진이 apex 별칭을 고치려고 설계된 그 레코드를 보고 어깨를 으쓱한다는 뜻이다.
그래서 2026년 기술 현주소는 이렇다: apex CNAME 문제는 발표된 표준으로 해결됐는데, 클라이언트가 그 표준을 구현하지 않았다. Chromium과 Firefox가 우선순위 0 HTTPS 레코드를 따르는 법을 배우기 전까지, 당신은 여전히 제공업체의 flattening 편법과 벌거벗은 도메인을 아예 포기하는 것 사이에서 고르는 신세다.
그래서 실제로 뭘 해야 하나
오늘 apex를 CDN이나 호스트명으로 가리켜야 한다면 — 거의 확실히 그럴 텐데 — 제공업체의 flattening을 써라. 실용적인 답이고 대부분의 사이트에 충분하다. 다만 뭘 맞바꿨는지는 알아 둬라: 대상의 해석을 당신 네임서버로 옮긴 것이니, 지리에 민감한 걸 돌린다면 DNS가 “맞아 보인다”고 믿는 대신 방문자가 실제로 어디로 보내지는지 확인해라. flattened 레코드의 TTL도 확인하고.
그리고 누군가 자신 있게 “그냥 루트에 CNAME 하나 추가하면 돼”라고 하면, 이제 정직한 대답을 안다: 못 한다, 아무도 못 한다, 우리 대부분이 DNS 레코드를 쓰기 시작하기도 전에 스펙이 금지했고, 깔끔한 대체재는 3년째 RFC 9460 안에 앉아 브라우저가 따라잡기를 기다리고 있다.