맨위로가기

CNAME 레코드

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

CNAME 레코드는 도메인 네임 시스템(DNS)에서 사용되는 레코드 유형으로, 특정 도메인 이름에 대한 별칭을 정의한다. CNAME 레코드는 다른 도메인 이름을 가리키며, DNS 리졸버는 CNAME 레코드를 만나면 해당 별칭 대신 정식 이름으로 쿼리를 다시 시작한다. CNAME 레코드는 IP 주소를 직접 가리킬 수 없으며, 존 에이펙스에 존재할 수 없고, MX 레코드, NS 레코드 또는 SMTP 관련 도메인에 사용될 수 없다는 제약이 있다. DNAME 레코드는 하위 트리에 대한 리디렉션을 제공하는 반면, ANAME 레코드는 일부 관리형 DNS 플랫폼에서 CNAME과 유사하게 사용되며 존 에이펙스에서 사용 가능하다는 장점이 있다.

더 읽어볼만한 페이지

  • DNS 레코드 타입 - TXT 레코드
    TXT 레코드는 DNS에서 임의의 텍스트 데이터를 저장하는 데 사용되며, 도메인 소유권 확인, SPF 구현, 전자우편 메시지 발신자 확인, 제로 컨피규레이션 네트워킹, DMARC 정책 등 다양한 목적으로 활용된다.
CNAME 레코드
CNAME 레코드
종류DNS 레코드
설명하나의 도메인 이름을 다른 도메인 이름의 별칭으로 지정
CNAME 레코드
영어 명칭Canonical Name record
RFCRFC 1035

2. 상세 설명

DNS CNAME 레코드는 RFC 1034에 정의되어 있으며 RFC 2181의 섹션 10에 분명히 명시되어 있다.[1] CNAME 레코드는 DNS에서 특별하게 관리되며 사용상 여러 제약이 따른다.

2. 1. 작동 원리

DNS 리졸버가 정규 리소스 레코드를 찾는 동안 CNAME 레코드를 마주칠 때 원래의 이름 대신 정식 이름을 사용하여 쿼리를 다시 시작한다. (리졸버가 CNAME 레코드를 찾을 경우 쿼리를 재시작하지 않고 정식 이름이 반환된다.) CNAME 레코드가 가리키는 정식 이름은 각기 다른 DNS 존 내 원격 서버든 로컬 서버든지에 관계 없이 DNS 어느 곳이든 위치할 수 있다.[1]

예를 들어 DNS 존이 다음과 같이 있다고 하면:

NAMETYPEVALUE
bar.example.com.CNAMEfoo.example.com.
foo.example.com.A192.0.2.23



A 레코드가 'bar.example.com'를 찾을 때 리졸버는 CNAME 레코드를 보고 'foo.example.com'에서 확인을 재시작한 뒤 192.0.2.23을 반환한다.[1]

2. 2. 예시

다음과 같은 DNS 존이 있다고 가정해 보자.

NAMETYPEVALUE
bar.example.com.CNAMEfoo.example.com.
foo.example.com.A 레코드192.0.2.23



`bar.example.com`에 대한 A 레코드 조회가 수행되면 DNS 리졸버는 CNAME 레코드를 보고 `foo.example.com`에 대한 조회를 다시 시작하여 192.0.2.23을 반환한다.

2. 3. CNAME 레코드 관련 혼동

CNAME 레코드를 사용하면 "bar.example.com"과 같은 이름을 "foo.example.com"으로 지정할 수 있다. 이 때문에 일상적인 대화에서 DNS 항목의 "bar.example.com"(왼쪽) 부분을 "CNAME" 또는 "a CNAME"으로 잘못 부르는 경우가 있다. 그러나 이것은 정확하지 않다. "bar.example.com"의 정식(진정한) 이름은 "foo.example.com"이다. CNAME은 정식 이름(Canonical Name)을 의미하므로, 오른쪽이 실제 "CNAME"이며, 주소 "A"와 같은 쪽에 있다.[2]

이러한 혼란은 RFC 2181 "DNS 사양에 대한 설명"에서 구체적으로 언급되었다. 왼쪽 레이블은 오른쪽 부분(RDATA 부분)의 별칭이며, 이것이 정식 이름이다.[2] 즉, 다음과 같이 CNAME 레코드를 읽을 수 있다.

:"bar.example.com"은 정식 이름(CNAME) "foo.example.com"의 별칭이다. 클라이언트는 "bar.example.com"을 요청하고, 응답은 "foo.example.com"이 된다.

3. 제약 사항

CNAME 레코드는 DNS에서 특별하게 관리되며 사용상 여러 제약이 따른다.


  • CNAME 레코드는 항상 다른 도메인 이름을 가리켜야 하며, IP 주소를 가리켜서는 안 된다.
  • 노드에 CNAME 레코드가 있으면 다른 데이터는 없어야 한다. 이렇게 하면 정식 이름과 해당 별칭에 대한 데이터가 다를 수 없도록 보장된다. (RFC 1034 섹션 3.6.2, RFC 1912 섹션 2.4) 단, DNSSEC를 사용하는 경우에는 RRSIG, NSEC 등과 같은 DNSSEC 관련 레코드가 있을 수 있다. (RFC 2181 섹션 10.1)
  • 다른 CNAME 레코드를 가리키는 CNAME 레코드는 비효율적이므로 피해야 하지만, 오류는 아니다.[3]
  • CNAME 레코드는 존(zone) 에이펙스(apex)에 존재할 수 없다. RFC 1034 섹션 4.2.1[4]은 존 에이펙스에 SOA 레코드가 있어야 한다고 요구하고, RFC 1034 섹션 3.6.2[5]는 CNAME 레코드가 있으면 다른 레코드가 없어야 한다고 요구한다. 따라서 CNAME 레코드는 존 에이펙스에 나타날 수 없다.
  • MX 레코드 및 NS 레코드는 CNAME 별칭을 가리켜서는 안 된다 (RFC 2181 섹션 10.3).
  • SMTP MAIL 및 RCPT 명령에 사용되는 도메인은 CNAME 레코드를 가질 수 없다.[6]

4. DNAME 레코드

DNAME record영어 또는 위임 이름 레코드는 RFC 6672에 의해 정의된다(원래 RFC 2672는 이제 더 이상 사용되지 않음). DNAME 레코드는 DNS에서 도메인 이름 트리의 하위 트리에 대한 리디렉션(별칭)을 제공한다. 즉, 특정 접미사로 끝나는 모든 이름이 DNS의 다른 부분으로 리디렉션된다. 이와 대조적으로, CNAME 레코드는 단일 이름에 대한 별칭을 생성하며 해당 하위 도메인에 대해서는 생성하지 않는다.[1] CNAME 레코드와 마찬가지로 DNS 조회가 새 이름으로 다시 시도하여 계속된다.[1] 네임 서버는 요청된 이름에 DNAME 레코드를 실제로 적용하기 위해 CNAME 레코드를 합성한다.[1] 하위 트리의 모든 노드에 대한 CNAME은 전체 하위 트리에 대한 DNAME과 동일한 효과를 갖는다.[1]

예를 들어, 다음과 같은 DNS 영역이 있다고 가정해 보자.[1]

DNS 영역 예시



''foo.example.com''에 대한 '''A''' 레코드 조회를 하면 DNAME은 CNAME이 아니고 ''foo''에 직접 A 레코드가 없으므로 데이터가 반환되지 않는다.[1]

그러나 ''xyzzy.foo.example.com''에 대한 조회를 하면 DNAME 매핑되어 ''xyzzy.bar.example.com''에 대한 '''A''' 레코드인 192.0.2.24를 반환한다.[1] DNAME 레코드가 CNAME 레코드였으면 이 요청은 이름을 찾을 수 없다는 결과를 반환했을 것이다.[1]

마지막으로, ''foobar.foo.example.com''에 대한 요청은 DNAME 매핑되어 192.0.2.25를 반환한다.[1]

5. ANAME 레코드

여러 관리형 DNS 플랫폼은 비표준 ALIAS[8] 또는 ANAME[9] 레코드 유형을 구현한다. 이러한 가상 레코드는 CNAME 레코드와 유사하게 DNS 관리자에 의해 관리되지만, 일부 DNS 클라이언트에 의해 A 레코드와 같이 게시되고 확인된다. ANAME 레코드는 일반적으로 다른 도메인을 가리키도록 구성되지만, 클라이언트가 쿼리할 때 IP 주소로 응답한다. ANAME 레코드 유형은 표준화를 위해 제출되었지만,[10] 다른 비표준 구현도 존재하므로, DNS 플랫폼 소유자가 선택하는 모든 작업을 수행할 수 있다. 여기에는 존의 최상위에 존재하고 메일을 수신하는 도메인에 존재하는 것도 포함된다.

ANAME 레코드는 CNAME 레코드에 비해 존 에이펙스에서 사용할 수 있다는 주요 장점이 있다. 표준을 준수하는 리졸버는 CNAME 레코드가 있는 도메인 이름을 존 에이펙스로 취급하지 않는다.[11] 또한, DNS 클라이언트는 CNAME을 A 레코드로, 다시 IP 주소로 확인하기 위해 최소 두 번의 쿼리가 필요하지만, ANAME은 두 번째 및 후속 쿼리를 서버로 전송한다. DNS 서버가 A 레코드를 확인하고 요청된 IP 주소를 DNS 클라이언트보다 더 효율적으로, 더 낮은 지연 시간으로 캐시할 수 있다면, DNS 클라이언트는 쿼리를 더 빠르게 해결할 수 있다.

ANAME 레코드 유형은 IETF에 초안 표준으로 제출되었다. 그러나 최신 초안 문서는 2020년 1월에 만료되었으며,[10] 일련의 제안에 의해 대체되었으며, 가장 최근의 제안은 SVCB 및 HTTPS 레코드 유형에 대한 제안이다.[12]

참조

[1] 웹사이트 RFC 1035 - Domain names - implementation and specification https://tools.ietf.o[...] Internet Engineering Task Force 1987-11
[2] 웹사이트 RFC 2181: Clarifications to the DNS Specification http://tools.ietf.or[...] IETF 1997-07
[3] 웹사이트 RFC 1034 - Domain names - concepts and facilities https://tools.ietf.o[...] Internet Engineering Task Force 1987-11
[4] 웹사이트 RFC 1034 section 4.2.1 https://tools.ietf.o[...] 1987-11
[5] 웹사이트 RFC 1034 section 3.6.2 https://tools.ietf.o[...] 1987-11
[6] 웹사이트 RFC1123 - MAIL - SMTP & RFC-822 https://tools.ietf.o[...] 1989-10
[7] 웹사이트 CNAME records in mail http://cr.yp.to/im/c[...]
[8] 웹사이트 ALIAS Records https://support.dnsi[...]
[9] 웹사이트 ANAME Records https://dnsmadeeasy.[...]
[10] 웹사이트 Address-specific DNS aliases (ANAME) https://tools.ietf.o[...] 2019-07-08
[11] 웹사이트 CNAME at the apex of a zone https://kb.isc.org/d[...] Internet Systems Consortium
[12] 웹사이트 Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) https://datatracker.[...] 2023-03-11
[13] 웹인용 RFC 1035 - Domain names - implementation and specification https://tools.ietf.o[...] Internet Engineering Task Force 1987-11


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com