CNAME(Canonical Name) 레코드는 특정 도메인 이름이 다른 도메인 이름의 별칭으로 사용되도록 설정하는 데 사용된다. 예컨대, example.com이라는 도메인이 실제로 www.example.com을 가리키게 하려면, CNAME 레코드를 설정할 수 있다. 이를 통해 example.com에 대한 쿼리가 자동으로 www.example.com으로 리디렉션 된다. 이렇게 함으로써 도메인 관리가 간편해지며, 한 도메인 이름에 여러 별칭을 손쉽게 연결할 수 있게 된다.
RFC 1034와 RFC 1035는 DNS 시스템의 설계와 구현을 규정하는 문서로, CNAME 레코드와 다른 유형의 레코드가 함께 존재할 수 없도록 명확히 규정하고 있다. 이 규정은 CNAME 레코드가 설정된 도메인에는 다른 유형의 레코드(A, MX, TXT 등)를 포함할 수 없음을 명시한다. 이러한 제한은 몇 가지 중요한 이유에서 기인한다.
첫째, 데이터의 일관성을 유지하기 위해서다. CNAME 레코드는 도메인의 모든 쿼리를 지정된 다른 도메인으로 리디렉션 하기 때문에, 동일한 도메인에 다른 레코드가 존재하면 어떤 레코드를 반환해야 할지 명확하지 않다. 예를 들어, example.com에 CNAME 레코드와 A 레코드가 동시에 존재한다면, example.com에 대한 쿼리가 IP 주소를 반환해야 하는지, 아니면 별칭 도메인으로 리디렉션해야 하는지 혼란이 발생할 수 있다. 이러한 모호성은 네트워크 통신에 문제를 일으킬 수 있으며, 예측 가능한 동작을 보장하기 위해 피해야 한다.
둘째, DNS 표준의 준수를 위해서다. RFC 1034와 RFC 1035는 CNAME 레코드가 설정된 도메인에는 다른 유형의 레코드를 포함할 수 없다고 명시한다. 이는 CNAME 레코드의 본래 목적을 지키기 위함이다. CNAME 레코드는 도메인을 다른 도메인으로 완전히 대체하는 역할을 하기 때문에, 원래 도메인의 다른 레코드가 무시되거나 잘못된 정보가 반환될 수 있다. 따라서 DNS 표준은 이러한 혼란을 방지하기 위해 CNAME 레코드와 다른 레코드의 공존을 금지하고 있다.
AWS Route53에서도 위 표준을 준수하고 있어서, CNAME 레코드를 넣을 때 다른 레코드가 존재하면 에러가 발생한다. 다음과 같이 example.techchallengearena.com으로 txt 레코드를 넣은 상태에서, CNAME을 넣으면 에러가 발생하는 것을 볼 수 있다.
실제 DNS 서버 코드인 BIND9 코드를 살펴보면 다음과 같이 cname_and_other_data라는 함수를 통해 위 사항을 체크한다.
그런데, 로직을 보면 DNSSEC과 관련된 레코드는 예외인 것을 알 수 있다. 이에 대한 내용은 RFC4034를 보면 정확하게 알 수 있다. RFC 4034는 DNSSEC 서명된 영역에서 RRSIG(Resource Record Signature)와 NSEC(NEXT Secure) 레코드가 CNAME과 함께 존재할 수 있음을 명시하고 있다. 이는 DNS 응답의 무결성과 인증을 보장하기 위한 보안 확장으로, CNAME 레코드의 본래 목적을 훼손하지 않으면서도 보안을 유지할 수 있도록 설계되었다.