요약

  • CNAME은 한 DNS 소유자 이름을 정확히 하나의 대상에 대한 별칭으로 만들었습니다. 별칭과 그 목적지가 서로 충돌하는 답을 내지 않도록, 별칭 소유자는 일반 A, MX, TXT, NS 등 응용 데이터를 동시에 가질 수 없었습니다.
  • 리졸버는 CNAME을 캐시하고 대상에서 조회를 다시 시작합니다. 우회는 소스 존이 통제하고, 최종 데이터는 대상의 권한이 통제합니다. 어느 쪽도 위임이나 신원 증명, 서비스 보장이 아닙니다.

하나의 이름이 서로 양립할 수 없는 두 가지 역할을 하려 했다

portal.example이service.example.net에 대한 CNAME으로 공개되어 있다고 가정해 봅시다. 클라이언트가 그 주소를 질의하면, 소스 서버는 별칭 지시를 반환하고 리졸버는 대상에서 조회를 계속할 수 있습니다. 이제 소스가portal.example에 자체 A 레코드까지 공개하고 있다면, 캐시는 어느 주소를 믿어야 할까요? 오래된 이름에 붙은 주소인가, 별칭을 따라 도달한 주소인가?

초기의 DNS는 이 충돌을 선호도에 맡기기를 거부했습니다. 1987년 11월에 공개된RFC 1034에서 Paul Mockapetris는 CNAME을 특수 자원 레코드로 정의했습니다. 소유자 이름은 별칭이고, RDATA는 정식(canonical) 목적지를 가리킵니다. CNAME이 노드에 존재하면 그곳에 다른 일반 데이터가 있어서는 안 됩니다.

이는 단순히 깔끔한 존 파일 스타일의 문제가 아니었습니다. 명세는 두 가지 아키텍처적 이유를 제시했습니다. 정식 이름과 그 별칭들의 데이터는 서로 갈라져서는 안 된다는 점, 그리고 CNAME을 캐시한 리졸버가 같은 소유자에 다른 레코드 타입이 있어 우회와 모순되는지를 소스 권한에 다시 물어보지 않고도 이를 사용할 수 있어야 한다는 점입니다.

따라서 배타성은 작은 권한 조각을 만들어 냈습니다. 캐시된 CNAME은 어떤 주소, 메일 교환기 또는 서비스가 존재하는지 말하지 않습니다. 리졸버가 어디에서 다시 질의해야 하는지만을 말합니다.

응답이 질문 자체를 바꾸었다

CNAME은 단순히 다른 철자를 불활성 데이터로 돌려주는 것이 아닙니다. DNS 처리 자체를 바꿉니다. 요청된 타입이 CNAME이 아니라면, RFC 1034는 이름 서버에게 CNAME RR을 응답에 복사하고, 작업 중인 QNAME을 대상 이름으로 바꾼 뒤 조회 알고리즘의 처음으로 돌아가도록 지시합니다. CNAME 자체를 질의하는 경우는 예외입니다. 질의자가 우회를 들여다보려 한 것이므로, 해석은 그것을 따라가지 않습니다.

RFC 9499의 현대 용어는 이 이동을 보이게 만듭니다. 원래 QNAME은 질문에 담긴 이름이고, 실효 QNAME은 CNAME 단계 이후 실제로 해석된 이름이며, 최종 QNAME은 체인의 마지막 이름입니다. 하나의 DNS 응답은 원래 질문을 그대로 되울리면서 소유자가 최종 이름인 답을 실을 수 있습니다.

이 구분은 끝이 실패할 때 중요해집니다. 대상이 없거나 일시적으로 도달 불가능하거나 다른 존에 속해 있더라도, 별칭은 존재하며 권위적으로 응답될 수 있습니다. 최종 QNAME에서의 부정 결과는 원래 별칭이 존재하지 않았음을 소급해 증명하지 않습니다.

우회는 위임이 아니었다

DNS 위임과 DNS 별칭은 모두 리졸버를 다른 곳으로 계속 보내지만, 옮기는 것이 서로 다릅니다. 존 컷에 있는 NS RRset은 하위 존에 대한 권한을 보유한 서버들을 식별합니다. CNAME은 자신의 소스 이름에 대한 권한 주체가 공개한 데이터로 남습니다. 리졸버에게 다른 조회를 시작하라고 지시할 뿐, 소스 존을 대상 운영자에게 넘겨주지 않습니다.

소스 존 관리자는portal.example을 만들고, 바꾸고, 삭제할 수 있으며 TTL도 정합니다.service.example.net에 권한 있는 운영자는 대상의 A, AAAA 등 터미널 데이터와 그 TTL을 통제합니다. 소스가 대상을 가리킨다고 해서 대상에 대한 권한을 얻지 않으며, 대상도 소스 별칭을 편집할 권한을 얻지 않습니다.

RFC 6604는 이후 CNAME과 DNAME 체인을 넘나드는 상태 처리를 명확히 했습니다. 응답은 별칭 단계에 대해 권위적일 수 있으면서도 나중에 발생한 리퍼럴이나 실패를 담을 수 있습니다. 첫 진술에 대한 권한이 전 여정에 대한 권한은 아닙니다.

하나의 별칭, 하나의 대상 — 한 대의 기계, 하나의 이름이 아니다

“canonical”이라는 단어는 과잉 해석을 부추렸습니다. DNS가 모든 호스트나 인터페이스에 공식 이름을 하나만 허용하는 것처럼 들릴 수 있었습니다.RFC 2181은 그 추론을 배격했습니다. DNS는 호스트에 일반적인 단일 이름 신원 규칙을 부과하지 않습니다.

더 좁은 규칙은 정확합니다. 하나의 CNAME 소유자는 하나의 정식 대상을 갖습니다. RFC 2181은 또한 소유자를 “a CNAME”이라 부르는 표현이 방향을 흐릴 수 있다고 경고합니다. 소유자는 별칭이고, 레코드 안의 도메인 이름이 그 별칭 동작에 대한 정식 이름입니다.

이 정밀함은 프로토콜 상태와 신원 주장을 분리합니다. 여러 도메인 이름이 합법적으로 같은 서비스로 이어질 수 있습니다. 별칭이 아닌 이름은 여러 일반 RRset을 가질 수도 있습니다. 불가능한 것은 자신을 CNAME 우회로 선언하면서 동시에 독립적인 목적지로 동작하는 것입니다.

존 정점(apex)이 지름길을 쓸 수 없었던 이유

배타성 규칙은 익숙한 구조적 결과를 낳습니다. 존 정점에는 SOA와 NS 데이터가 있어야 합니다. CNAME 소유자는 그런 일반 레코드를 동시에 가질 수 없으므로, 정점은 일반적인 CNAME일 수 없습니다.

RFC 1912는 이 유혹적인 구성이 얼마나 위험할 수 있었는지를 기록했습니다. 그 역사적 BIND 예제는 정점 NS 레코드 옆에 CNAME을 놓았고, 서버는 CNAME을 선호해 다른 자원들을 무시하여 존 아래의 이름들이 사라질 수 있었습니다. 정확한 동작은 그 시대 구현들에 속하지만, 충돌 자체는 데이터 모델에 속합니다.

주소 응답을 합성하거나 정점을 “플래튼(flatten)”하는 서비스들은 유용한 제품 동작을 제공할 수 있습니다. 그러나 그들이 와이어 상의 CNAME RR 의미를 바꾸지는 않습니다. 모든 공급자 편의를 “apex CNAME”이라 부르면, 권한과 캐싱을 진단할 때 운영자에게 필요한 바로 그 구분이 지워집니다.

일부 대상 위치는 별칭을 허용하지 않았다

이 규칙은 다른 도메인 이름을 담는 레코드에도 미칩니다. RFC 2181에 따르면 NS 대상과 MX 레코드의 교환기 부분은 별칭이어서는 안 됩니다. NS와 MX 질의는 추가 섹션 처리를 유발합니다. 서버는 명명된 서버나 교환기의 주소 레코드를 덧붙일 수 있습니다. 그 처리는 CNAME을 따라간 뒤 정식 대상의 주소를 덧붙이는 방식으로 동작하지 않습니다.

그런 위치에서 별칭을 쓰면 질의와 네트워크 부하가 늘어나고, 어려운 경우, 특히 위임 주변에서는 주소가 빠져 해석이 실패할 수 있습니다. NS나 MX 데이터를 쓰는 관리자는 별칭을 한 번 해석해 주소 레코드를 소유한 직접 이름을 공개하는 것이 기대됩니다.

이것은 이름이 다른 이름을 가리키는 것에 대한 보편적 금지가 아닙니다. 예측 가능한 주소 발견에 의존하는 프로토콜 경로를 암묵적 추가 해석 단계가 무너뜨릴 수 있는 위치에 관한 규칙입니다.

DNSSEC는 증명을 더하되 두 번째 목적지는 복원하지 않았다

“다른 데이터 없음”이라는 표현은 DNSSEC가 발전하면서 중요한 자격 조건을 얻었습니다. RFC 2181은 당시의 보안 레코드가 CNAME 옆에 있음을 허용했습니다.RFC 4034는 이후 서명된 존의 CNAME 소유자에 RRSIG와 NSEC 레코드를 요구했습니다.

그 레코드들은 대상과 경쟁하지 않습니다. RRSIG는 CNAME RRset을 인증하고, NSEC는 인증된 부정과 타입 증거에 참여합니다. 이들은 별칭 노드의 상태를 증명합니다. 그 노드에 독립적인 주소, 메일 경로, 텍스트 페이로드를 주지는 않습니다.

RFC 4033은 보안 주장의 한계를 유지합니다. DNSSEC는 검증이 성공하면 데이터 출처 인증, 무결성, 인증된 부정을 제공합니다. 그러나 대상을 인증된 응용, 건강한 서비스, 계약 상대방 또는 소스 이름의 법적 소유자로 만들지는 않습니다.

체인은 허용되었지만 루프는 아니었다

하나의 별칭이 다른 별칭으로 이어질 수 있습니다. RFC 1034는 매 단계가 작업을 더하므로 다단계를 권하지 않지만, 유한한 체인을 오류로 만들지는 않습니다. 대신 리졸버는 루프와 존재하지 않는 이름으로 끝나는 별칭을 잡아 클라이언트에 오류 조건을 반환해야 합니다.

따라서 운영 대상은 문자열 치환이 아니라 그래프입니다. 각 간선에는 소유자, 권한, TTL, 그리고 가능하다면 DNSSEC 상태가 있습니다. 마지막 이름에는 자체 레코드와 수명이 있습니다. 한 캐시에서 작동하던 체인은 다른 캐시에서 실패할 수 있으며, 오래된 간선들은 서로 다른 시점에 만료됩니다.

이것이 분리의 대가입니다. 소스 운영자는 대상 데이터를 복제하지 않고도 익숙한 이름을 옮길 수 있습니다. 대상 운영자는 모든 별칭 존을 편집하지 않고도 주소를 바꿀 수 있습니다. 그러나 양쪽은 독립적으로도 바뀌며, 캐시는 해당 TTL이 만료될 때까지 이전 진술을 보존합니다.

섞인 진실을 거부함으로써 최소한의 조율이 살아남았다

CNAME은 의도적으로 얇은 원시 요소로 분산 유지보수 문제를 풀었습니다. 공유 프로토콜에는 동등한 이름들의 글로벌 레지스트리도, 어떤 주소가 별칭에 “진짜로” 붙어 있는지 판정하는 중앙 조정자도 필요하지 않았습니다. 어떤 리졸버든 캐시하고 따라갈 수 있는 하나의 모호하지 않은 간선이 필요했습니다.

배타성 규칙이 그 설계의 헌법적 중심입니다. 소스 이름은 우회이거나 목적지일 수 있지만 둘 다일 수는 없습니다. 우회를 선택한 순간, 그 권한은 실재하면서도 좁습니다. 하나의 대상을 공개하고, 체인의 증거를 보존하고, 목적지의 데이터는 목적지를 통제하는 자에게 맡기는 것입니다.

출처와 한계

원래 모델과 해석 알고리즘은 RFC 1034와RFC 1035에서 옵니다. 운영상 오류와 명명 관련 명확화는 RFC 1912와 RFC 2181에서 옵니다. DNSSEC 예외는 RFC 4033과 RFC 4034에서, 체인 상태와 현재 용어는 RFC 6604와 RFC 9499에서 옵니다. 이 문서들은 현재의 배포 점유율, 공급자별 플래튼 처리, 리졸버 체인 한도, 매달린 별칭의 prevalence, 응용 소유권 또는 어떤 현재 서비스의 가용성도 확립하지 않습니다.