인기 도구

테마

CNAME 조회 — CNAME 레코드 확인

CNAME 조회로 모든 이름의 CNAME 레코드를 확인하세요: 각 존 자체 네임서버에 물어 CNAME 체인을 단계별로 따라가며, 모든 별칭과 그 TTL, 응답한 서버, 대상 뒤의 플랫폼, 최종 주소를 보여 줍니다. 대상이 사라진(댕글링) CNAME, 루프, 너무 긴 체인은 해결 방법과 함께 알려 줍니다.

출처: 루트 서버에서 찾아간 각 존 자체 네임서버 · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru

입력한 그대로 조회합니다: www.와 서브도메인은 바꾸지 않으며, IDN은 퓨니코드(punycode)로 보냅니다.

예시

CNAME이란? CNAME 레코드의 뜻

CNAME(canonical name, 정식 이름) 레코드는 한 이름을 다른 이름의 별칭으로 만듭니다. 별칭을 조회하면 DNS는 '대신 이 다른 이름을 조회하라'고 응답합니다. 값은 항상 이름이며, IP 주소가 될 수 없습니다(RFC 1034 §3.6.2).

리졸버가 별칭을 대신 따라가 같은 응답에 대상의 주소를 돌려주므로 브라우저는 차이를 알아채지 못합니다. 플랫폼이 CNAME을 요구하는 이유가 여기에 있습니다: www를 플랫폼의 이름으로 한 번만 지정해 두면, 내가 DNS를 건드리지 않아도 플랫폼이 서버를 옮길 수 있습니다.

엄밀히 말하면 정식 이름은 대상 쪽이며, 별칭을 "CNAME"이라고 부르는 것은 흔히 쓰는 줄임말입니다. CNAME이 있는 이름에는 다른 레코드를 둘 수 없고 CNAME도 하나만 둘 수 있으므로(RFC 2181 §10.1), SOA와 NS 레코드가 반드시 있어야 하는 존의 최상위에는 CNAME을 둘 수 없습니다(RFC 1034 §4.2.1).

부분별로 본 CNAME 레코드www.microsoft.com · 2026. 10. 23. 기록
www.microsoft.com.별칭(소유자)3600TTLIN클래스CNAME유형www.microsoft.com-c-3.edgekey.net.정식 이름(대상)
별칭사람들이 입력하거나 링크하는 이름입니다. 이 레코드 하나만 가지며 다른 레코드는 없습니다.
TTL · 1시간리졸버가 다시 묻기 전까지 이 레코드를 보관할 수 있는 시간입니다.
대상다음에 찾아볼 곳: Akamai의 엣지 이름입니다. 항상 이름이며, 주소가 될 수 없습니다.
  1. 조회하는 이름www.github.com
  2. CNAME · 1시간
  3. 정식 이름github.com
  4. A · 1분
  5. 주소 · AS8075 Microsoft20.207.73.82
  • www.github.comCNAMEgithub.com같은 도메인
  • www.rust-lang.orgCNAMErust-lang.github.ioGitHub Pages
  • www.cursor.comCNAMEcname.vercel-dns.comVercel
  • docs.github.comA185.199.108.154+3개 더별칭 없음: 자체 주소
각 존 자체 네임서버에서 기록했습니다. www.github.com을 질의하는 리졸버는 별칭과 github.com의 주소를 한 응답으로 받습니다.

CNAME 레코드 확인 방법: nslookup과 dig로 CNAME 조회

위에 이름을 입력하고 CNAME 조회를 누르세요: 도구가 각 존 자체 네임서버에 단계별로 질의하고 체인을 그려 줍니다. 컴퓨터에서는 dig 한 줄이면 됩니다: A 유형으로 질의하면 응답에 모든 별칭이 먼저, 그다음에 주소가 나옵니다.

CNAME 유형으로 질의하면 첫 번째 별칭만 보입니다. Windows에서는 nslookup -type=cname 명령으로, PowerShell에서는 Resolve-DnsName -Type CNAME 명령으로 CNAME을 조회하며, host -t cname 명령은 결과를 한 문장으로 출력합니다.

주의할 점 두 가지: 리졸버는 존이 정한 TTL이 아니라 캐시에 남은 TTL을 보여 주며, dig +short 옵션은 TTL과 소유자 이름을 빼 버리므로 체인이 단순한 목록으로만 출력됩니다.

dig www.example.com A +noall +answer

모든 별칭을 TTL과 함께 보여 준 다음 주소를 출력합니다. +short를 붙이면 TTL 없이 대상만 출력합니다.

dig 출력 해설www.nytimes.com, 8.8.8.8 경유 · 2026. 10. 23.
bash · dig
$ dig www.nytimes.com A +noall +answer
www.nytimes.com.                  12902IN  CNAME www.prd.map.nytimes.com.3
www.prd.map.nytimes.com.             482   IN  CNAME www.prd.map.nytimes.xovr.nyt.net.
www.prd.map.nytimes.xovr.nyt.net.    260   IN  CNAME nytimes.map.fastly.net.
nytimes.map.fastly.net.               28   IN  A     151.101.1.1644
nytimes.map.fastly.net.               28   IN  A     151.101.129.164
nytimes.map.fastly.net.               28   IN  A     151.101.193.164
nytimes.map.fastly.net.               28   IN  A     151.101.65.164

$ dig www.nytimes.com +short5
www.prd.map.nytimes.com.          # TTL 없음, 소유자 이름 없음
www.prd.map.nytimes.xovr.nyt.net.
nytimes.map.fastly.net.
151.101.1.164
151.101.129.164
151.101.193.164
151.101.65.164
  1. 질의한 이름. 각 줄의 첫 번째 열은 레코드의 소유자입니다.
  2. Google 캐시에 남은 시간: 존의 TTL 600초 중 290초. 존 자체 서버는 전체 TTL을 보여 줍니다.
  3. CNAME → 다음 이름. 여기에는 별칭이 3개 있으므로 이런 줄도 3개입니다.
  4. 주소는 체인의 마지막 이름인 Fastly의 이름에 속하며, 존의 TTL은 1분입니다.
  5. +short 옵션은 TTL을 숨기고 소유자 이름도 숨깁니다: 대상과 주소만 남습니다.

다른 도구로 같은 질문하기

nslookup
$ nslookup -type=cname www.nytimes.com
Non-authoritative answer:
www.nytimes.com	canonical name = www.prd.map.nytimes.com.
PowerShell
PS> Resolve-DnsName www.nytimes.com -Type CNAME
# 레코드마다 한 행: 이름, 유형, TTL, 대상
host
$ host -t cname www.nytimes.com
www.nytimes.com is an alias for www.prd.map.nytimes.com.

macOS에서 출력되는 nslookup 결과입니다. Windows는 같은 응답을 조금 다르게 배치합니다.

CNAME 조회 결과 읽는 법

맨 위의 한 문장은 이름이 어디에 도달하는지, 별칭을 몇 개 거치는지를 플랫폼 로고와 함께 알려 줍니다. 그 아래의 메모가 중요한 발견 사항입니다. 개수는 CNAME 레코드의 수입니다: www.github.com → github.com은 2가 아니라 1입니다.

체인 보기는 각 레코드를 자기 존의 서버가 응답한 그대로 존, 서버, AA 플래그, TTL과 함께 나열하고, 이어서 판독 결과를 보여 줍니다: 루프, 길이, 존재하지 않는 대상, CNAME 옆의 다른 데이터. 사본 보기는 각 레코드에 대해 Google과 Cloudflare의 캐시된 사본을 존의 값과 나란히 놓습니다. 오른쪽의 남색 열은 체인을 그림으로 그립니다: 루프는 고리로, 존재하지 않는 대상은 끊긴 모양으로 표시합니다.

www.nytimes.com의 CNAME 조회 결과: Fastly로 이어지는 별칭 3개, 각 레코드의 TTL과 존, 주소까지 그린 CNAME 체인www.nytimes.com의 CNAME 조회 결과: Fastly로 이어지는 별칭 3개, 각 레코드의 TTL과 존, 주소까지 그린 CNAME 체인판정이름이 도달하는 곳, 거치는 별칭 수, 플랫폼, 주소의 네트워크.캐시된 사본각 레코드의 Google과 Cloudflare 사본, 각 사본의 남은 시간, 첫 레코드의 수정이 반영되는 시각.단계별 각 레코드존이 가진 그대로의 대상과 TTL, 응답한 서버, AA 플래그, 응답 시간.체인이름, 존과 TTL이 붙은 각 별칭, 그리고 최종 주소와 그 네트워크.
www.nytimes.com의 CNAME 조회 예시입니다. 판정, 존의 서버가 응답한 그대로의 각 별칭, 판독 결과, 오른쪽에 그린 체인을 보여 줍니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

CNAME 레코드와 A 레코드의 차이

A 레코드에는 주소가 들어 있습니다: docs.github.com → 185.199.108.154. CNAME에는 이름이 들어 있습니다: www.github.com → github.com이며, 주소는 그 이름 자체의 A 레코드에서 옵니다.

자체 서버와 루트 도메인에는 A 레코드를 쓰세요. 플랫폼이 가리킬 이름을 알려 줄 때(Vercel, GitHub Pages, CDN, 메일 서비스의 DKIM 키)는 CNAME을 쓰세요: 플랫폼이 서버를 옮겨도 레코드가 저절로 따라갑니다.

대가는 별칭마다 한 번씩 늘어나는 조회와 엄격한 규칙입니다: 그 이름에는 다른 레코드를 둘 수 없고, 존의 최상위에는 절대 둘 수 없습니다.

나란히 비교실제 레코드, 2026. 10. 23. 기록
CNAME별칭www.github.comA주소docs.github.com
가리키는 것다른 이름: github.comIPv4 주소: 185.199.108.154
루트(example.com)에 설정불가: 최상위에는 SOA와 NS가 있음가능
같은 이름의 다른 레코드없음: MX, TXT, A를 함께 둘 수 없음무엇이든: AAAA, MX, TXT…
추가 조회별칭마다 한 번: 여기서는 1번, www.nytimes.com은 3번없음
호스트가 옮겨 가면대상을 저절로 따라감주소를 직접 수정
용도플랫폼의 이름, CDN, DKIM 키자체 서버, 루트 도메인
CNAME: 두 단계www.github.comgithub.com20.207.73.82
A: 한 단계docs.github.com185.199.108.154

루트 도메인의 CNAME: ALIAS, ANAME, CNAME 플래트닝

도메인의 루트(github.com)는 존의 최상위이며, 최상위에는 존의 SOA와 NS 레코드가 반드시 있어야 합니다. CNAME은 옆에 어떤 레코드도 허용하지 않으므로 그곳에 둘 수 없습니다: 두 규칙이 충돌합니다(RFC 1034 §4.2.1, RFC 2181 §10.1).

DNS 호스트는 자체 서버에서 이 문제를 우회합니다: 대상을 직접 따라가 그 주소로 응답하는 방식입니다. Cloudflare는 이를 CNAME 플래트닝(CNAME flattening)이라고 부르고, Route 53은 별칭 레코드, DNSimple과 NS1은 ALIAS, DNS Made Easy는 ANAME이라고 부릅니다. 리졸버에는 A와 AAAA만 보이므로, 어떤 조회로도 그 뒤의 별칭을 볼 수 없습니다.

표준 ANAME은 없습니다: IETF 초안은 2019년에 만료되었습니다. 표준 방식은 AliasMode의 HTTPS 레코드(RFC 9460)이지만, 이 레코드를 질의하는 클라이언트만 사용하므로 루트에는 여전히 A 레코드가 필요합니다.

루트에 CNAME을 둘 수 없는 이유github.com · 존의 최상위, 2026. 10. 23.

github.com.존 최상위

  • SOAdns1.p08.nsone.net. hostmaster.nsone.net. …
  • NS서버 8대: NS1 + Route 53
  • MX github-com.mail.protection.outlook.com.
  • A20.207.73.82
  • CNAMEanything.example.net.

CNAME은 단독으로 있어야 하는데 이 레코드들은 반드시 여기 있어야 합니다: 그래서 루트에는 CNAME을 둘 수 없습니다.

DNS 호스트가 대신 제공하는 기능리졸버에 보이는 것

  • Cloudflare · CNAME 플래트닝모든 요금제에서 루트에 기본으로 켜져 있음A · AAAA
  • Amazon Route 53 · 별칭 레코드AWS 리소스나 같은 존의 레코드를 대상으로A · AAAA
  • DNSimple · ALIAS질의를 받을 때 대상을 조회A · AAAA
  • NS1 (IBM) · ALIASA · AAAA
  • DNS Made Easy · ANAMEA · AAAA
  • Azure DNS · 별칭 레코드 집합A · AAAA
  • AliasMode의 HTTPS 레코드 · RFC 9460유일한 표준: 서비스별로, 이 레코드를 요청하는 클라이언트용HTTPS
모든 업체의 기능은 일반 주소로 응답합니다. 그래서 어떤 조회 도구도 그 뒤의 별칭을 보여 줄 수 없습니다.

CNAME 체인, TTL, 변경이 반영되기까지 걸리는 시간

별칭은 다른 별칭을 가리킬 수 있습니다: www.microsoft.com은 별칭 2개를, www.nytimes.com은 3개를 거칩니다. 체인의 각 레코드는 TTL이 따로 있고 따로 캐시되므로, 사본이 만료되는 시점도 저마다 다릅니다(RFC 1034 §5.3.3).

그래서 가장 낮은 TTL이 곧 기다리는 시간은 아닙니다. Microsoft의 최종 주소는 20초만 유지되지만, 첫 번째 레코드, 즉 microsoft.com 자체 존에 있는 레코드의 수정은 그 레코드의 사본이 만료되기를 기다려야 합니다: 저희가 확인했을 때 Google의 사본은 37분, Cloudflare의 사본은 거의 1시간 전체가 남아 있었고, 어떤 리졸버든 최대 그 1시간 동안 보관할 수 있습니다.

체인은 짧게 유지하세요. RFC 9460은 연속된 별칭을 8개 이하로 권장합니다. 리졸버가 포기하는 한도는 BIND와 Unbound 11개, PowerDNS 10개, Knot 13개입니다. Google과 Cloudflare는 한도를 공개하지 않습니다.

레코드마다 시계가 따로 돕니다www.microsoft.com · 2026. 10. 23. 07:22:26 UTC 확인
  1. www.microsoft.comCNAME → www.microsoft.com-c-3.edgekey.net소유자가 수정하는 레코드1시간존의 TTL
    • Google36:37 남음 · 07:59:03까지
    • Cloudflare59:48 남음 · 08:22:14까지

    이 레코드의 수정은 Google에 07:59:03, Cloudflare에 08:22:14(UTC)까지 반영되며, 어떤 리졸버든 1시간 안에 반영됩니다.

  2. www.microsoft.com-c-3.edgekey.netCNAME → e13678.dscb.akamaiedge.net15분존의 TTL
    • Google6:58 남음 · 07:29:24까지
    • Cloudflare14:48 남음 · 07:37:14까지
  3. e13678.dscb.akamaiedge.netA 23.2.78.94가장 낮은 TTL20초존의 TTL
    • Google0:20 남음 · 07:22:46까지
    • Cloudflare0:08 남음 · 07:22:34까지

공개된 한도와 실제 체인

www.github.com별칭 1개www.microsoft.com별칭 2개www.nytimes.com별칭 3개www.apple.com별칭 3개
  • 8 RFC 9460: 8개 초과는 권장하지 않음
  • 10 PowerDNS
  • 11 BIND, Unbound
  • 13 Knot
  • Google, Cloudflare: 공개된 한도 없음
막대: 확인 시점에 각 캐시 사본에 남은 시간. 수정은 수정한 레코드의 사본이 만료되면 보이며, 가장 낮은 TTL은 그 부분을 얼마나 자주 다시 가져오는지만 알려 줍니다.

댕글링 CNAME과 서브도메인 탈취

CNAME의 대상이 사라지면 그 CNAME은 댕글링(dangling) 상태가 됩니다: 클라우드 앱이 삭제되었거나, 버킷이 비었거나, 도메인이 만료된 경우입니다. 다른 사람이 그 이름으로 리소스를 만들 수 있다면, 그 사람이 내 서브도메인에서 콘텐츠를 제공하고 유효한 인증서까지 받을 수 있습니다.

DNS에서는 CNAME이 그대로 담긴 NXDOMAIN 응답으로 나타납니다: 없는 것은 내 이름이 아니라 대상입니다(RFC 6604 §3). 이 방법은 리소스마다 고유한 DNS 이름을 주는 플랫폼에서만 통합니다. 다른 플랫폼은 어떤 이름에든 응답하므로 삭제된 사이트도 여전히 해석됩니다: 이런 곳에서는 사이트 자체를 확인하세요.

해결책은 순서입니다: 리소스보다 DNS 레코드를 먼저 삭제하고, 도메인 인증 기능을 제공하는 플랫폼에서는 도메인 소유권을 인증하세요. 고친 대상도 한동안은 없는 것처럼 보일 수 있습니다: 리졸버는 대상 존의 SOA TTL과 SOA의 minimum 필드 중 작은 값만큼 부정 응답을 보관합니다(RFC 2308 §5).

NXDOMAIN으로 알 수 있는 경우플랫폼 동작, 2026. 10. 23. 확인

없는 대상은 NXDOMAIN으로 응답

삭제된 리소스의 이름은 더 이상 해석되지 않습니다: 저희 판정은 댕글링입니다.

  • *.azurewebsites.netApp Service
  • *.trafficmanager.netTraffic Manager
  • *.blob.core.windows.netBlob Storage
  • *.cloudapp.netCloud Services
  • *.elasticbeanstalk.comElastic Beanstalk
  • *.elb.amazonaws.comElastic Load Balancing
  • *.pages.devCloudflare Pages
  • *.edgekey.net엣지 호스트 이름
  • *.map.fastly.net맵 이름

어떤 이름에든 응답하는 플랫폼

삭제된 사이트도 여전히 해석됩니다: 저희 판정은 플랫폼을 가리킴: 사이트가 아직 내 것인지 확인입니다.

  • *.github.ioGitHub Pages
  • *.netlify.appNetlify
  • *.herokuapp.comHeroku
  • *.vercel.appVercel
  • *.myshopify.comShopify
  • *.pantheonsite.ioPantheon
  • *.go-vip.netWordPress VIP
  • *.webflow.ioWebflow
  • *.zendesk.comZendesk
  • *.s3.amazonaws.comAmazon S3
  • *.azurefd.netAzure Front Door
  • *.global.ssl.fastly.netTLS 호스트 이름
지어낸 예시 · RFC 2606 이름
$ dig shop.example.com A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
;; ANSWER SECTION:     # 내 레코드는 그대로 있음
shop.example.com.   3600  IN  CNAME  example-shop.example.net.
;; AUTHORITY SECTION:  # 그런 대상 없음: 리졸버가 '없음'을 5분 동안 보관할 수 있음
example.net.         300  IN  SOA    ns1.example.net. …

탈취를 막는 소유권 확인

  • GitHub PagesTXT _github-pages-challenge-<user>.<domain>
  • Azure App ServiceTXT asuid.<subdomain>
  • WebflowTXT _webflow one-time-verification=…
  • Cloudflare for SaaSTXT 또는 HTTP로 호스트 이름 검증
  • Netlify고객 지원을 통한 도메인 잠금
CNAME이 그대로 담긴 NXDOMAIN 응답은 내 이름이 아니라 대상이 없다는 뜻입니다.

CNAME 레코드 추가 방법(GoDaddy, Cloudflare, Namecheap, Squarespace)

모든 DNS 관리 화면은 같은 세 가지를 묻습니다: 유형(CNAME), 호스트, 그리고 플랫폼이 알려 준 대상입니다. 호스트 입력란에는 www나 shop 같은 레이블만 입력하세요: 도메인은 관리 화면이 알아서 붙입니다.

전체 이름을 입력하면 www.example.com.example.com이 되며, 새 CNAME이 "작동하지 않는" 가장 흔한 이유입니다. 존 파일에서도 마찬가지로, 끝에 점이 없는 이름은 상대 이름으로 처리됩니다. Cloudflare에서 Proxied 레코드는 조회에서 CNAME을 숨깁니다: 플랫폼이 CNAME을 확인해야 한다면 DNS only로 설정하세요.

그런 다음 여기서 확인하세요. 호스트들은 1분에서 72시간까지 다양한 시간을 안내하지만, 변경한 레코드의 실제 대기 시간은 이전 레코드의 TTL이며, 완전히 새로 만든 이름은 보통 바로 보입니다.

같은 레코드, 관리 화면 4곳호스트 입력란 = 레이블만

GoDaddy대상 제공: Shopify

TypeCNAMENamewwwValueshops.myshopify.com

Name: blog나 shop처럼 도메인 이름 없이 입력하며, @ 기호는 쓰지 않습니다.

Cloudflare대상 제공: Webflow

TypeCNAMENamewwwTargetcdn.webflow.comProxy statusDNS only

Name: 서브도메인을 입력합니다. DNS only는 조회에서 CNAME이 보이게 두고, Proxied는 CNAME을 숨깁니다.

Namecheap대상 제공: Google

TypeCNAMEHostwwwValueghs.googlehosted.com

Host: mysubdomain.domain.tld 형식이 아니라 mysubdomain만 입력합니다.

Squarespace대상 제공: Framer

TypeCNAMENamewwwDatasites.framer.app

Name: Name 입력란에 @ 기호를 넣어서는 CNAME을 추가할 수 없습니다.

호스트에 입력: www.example.com저장되는 값: www.example.com.example.com. www만 입력하세요.

호스트의 안내와 TTL 비교

  • Route 53자체 서버에는 1분 이내
  • Namecheap30분
  • GoDaddy1시간, 최대 48시간기본 TTL 1시간
  • Hostinger최대 24시간기본 TTL 4시간
  • Squarespace24시간~48시간기본 TTL 4시간
  • Gandi최대 72시간
  • Gabia최대 48시간

호스트의 안내기본 TTL: 리졸버가 이전 레코드를 보관할 수 있는 시간

표시된 대상은 모두 해당 플랫폼이 문서화한 CNAME 대상입니다. 막대는 같은 시간 척도로 그렸으며, 완전히 새로 만든 이름은 보통 바로 보입니다.

Cloudflare 오류 1014: CNAME Cross-User Banned

오류 1014는 Cloudflare에 있는 이름이 CNAME으로 다른 Cloudflare 계정의 이름을 가리킬 때 나타납니다. 한 고객이 다른 고객의 설정을 거쳐 트래픽을 보내지 못하도록 Cloudflare가 차단하는 것입니다.

같은 존 안, 같은 계정의 존 사이, 그리고 대상 소유자가 내 이름을 사용자 지정 호스트 이름(custom hostname)으로 추가하는 Cloudflare for SaaS를 통해서는 허용됩니다. Cloudflare에서 실행되는 SaaS에 도메인을 연결할 때의 해결책이 바로 이것입니다. 다른 원인으로는 존이 보류(on hold) 상태인 R2 사용자 지정 도메인, 또는 차단된 존이 있습니다.

조회로는 가능성만 알려 줄 수 있습니다: 두 존이 모두 Cloudflare 네임서버를 쓴다면, 서로 다른 계정에 있을 경우 1014가 발생할 수 있습니다. DNS에는 존만 보이고 계정은 보이지 않으며, 프록시된(Proxied) 레코드는 CNAME 자체를 숨기므로 여기에는 DNS only 레코드만 나타납니다.

계정 둘, CNAME 하나지어낸 예시 · RFC 2606 이름

계정 A

shop.example.comCNAME → shops.example.net

1014계정 간 차단(Cross-User Banned)

계정 B

shops.example.net프록시됨 · SaaS 제공업체 자체 존

  • 같은 존www → example.com
  • 같은 계정한 존 → 같은 계정의 다른 존
  • Cloudflare for SaaS 이용대상 소유자가 내 호스트 이름을 추가

다른 원인: 존이 보류(on hold) 상태인 R2 사용자 지정 도메인, 또는 차단된 존.

이 도구가 알려 줄 수 있는 것: 두 존이 모두 *.ns.cloudflare.com에서 응답하면, 계정이 다를 경우 1014가 발생할 수 있습니다. DNS에는 존만 보이고 계정은 보이지 않습니다. *.cdn.cloudflare.net 대상은 Cloudflare의 CNAME setup(부분 설정)이며 SaaS가 아닙니다.

CNAME과 리다이렉트의 차이

CNAME은 리다이렉트가 아닙니다. DNS에 주소를 어디서 찾을지 알려 줄 뿐입니다: 브라우저는 주소창에 입력한 이름을 그대로 유지하고, 그 이름을 서버에 보내며, 그 이름에 대한 인증서를 기대합니다.

그래서 플랫폼은 자기 쪽에도 도메인을 추가하게 합니다: 플랫폼의 서버가 www.example.com을 인식하고 그 인증서를 제공해야 하기 때문입니다. 이름을 모르는 서버를 가리키는 CNAME은 기본 페이지나 인증서 오류를 보여 줍니다.

방문자를 한 URL에서 다른 URL로 보내려면 웹 서버에서 HTTP 리다이렉트(301 또는 308)를 쓰거나, 그런 서버를 대신 운영해 주는 DNS 호스트의 포워딩 기능을 쓰세요. 리다이렉트 확인 도구는 리다이렉트의 각 단계를 보여 줍니다.

브라우저에 보이는 것지어낸 예시 · RFC 2606 이름

CNAME이름이 그대로

www.example.com

  • DNS: www.example.com → CNAME sites.example.net → 그 주소
  • TLS: 인증서에 www.example.com이 들어 있어야 함
  • HTTP: Host: www.example.com 헤더: 서버가 이 이름을 알아야 함

301URL이 바뀜

www.example.net/

  • DNS: example.com → 웹 서버의 A 레코드
  • HTTP: 301 Location: https://www.example.net/ 응답
  • 브라우저: 새 URL을 불러오며, 새 URL은 따로 DNS 조회를 거침

CNAME 조회 자주 묻는 질문

CNAME 레코드란 무엇인가요?

CNAME 레코드는 한 이름을 다른 이름, 즉 정식 이름(canonical name)의 별칭으로 만듭니다. 리졸버가 별칭을 질의하면 응답은 대신 대상을 조회하라고 알려 주고, 주소는 대상 자체의 A 또는 AAAA 레코드에서 나옵니다. 값은 항상 이름이며 IP 주소가 될 수 없고, CNAME이 있는 이름에는 다른 레코드를 둘 수 없습니다.

CNAME 레코드는 어떻게 확인하나요?

위의 CNAME 조회 도구에 이름을 입력하세요: 각 존 자체 네임서버에 질의해 모든 별칭과 TTL, 그 뒤의 플랫폼, 최종 주소를 보여 줍니다. 컴퓨터에서는 macOS나 Linux에서 dig www.example.com CNAME, Windows에서 nslookup -type=cname www.example.com, PowerShell에서 Resolve-DnsName www.example.com -Type CNAME 명령을 실행하세요.

CNAME과 A 레코드는 무엇이 다른가요?

A 레코드에는 IPv4 주소가 들어 있고, CNAME에는 다른 이름이 들어 있어 그 이름의 주소를 빌려 씁니다. 루트 도메인과 자체 서버에는 A 레코드를 쓰세요. Vercel, GitHub Pages, CDN 같은 플랫폼이 가리킬 이름을 알려 주면 CNAME을 쓰세요. 그러면 플랫폼이 서버를 옮길 때 레코드가 따라갑니다.

루트 도메인에 CNAME을 설정할 수 있나요?

아니요. 루트는 존의 최상위로 SOA와 NS 레코드가 반드시 있어야 하는데, CNAME은 옆에 다른 레코드를 허용하지 않습니다. DNS 호스트는 일반 주소로 응답하는 우회 방법을 제공합니다: Cloudflare의 CNAME 플래트닝, Route 53 별칭 레코드, DNSimple과 NS1의 ALIAS, DNS Made Easy의 ANAME입니다. 유일한 표준은 AliasMode의 HTTPS 레코드입니다.

내 CNAME이 보이지 않는 이유는 무엇인가요?

흔한 이유는 네 가지입니다: Cloudflare가 레코드를 프록시하거나 플래트닝해 리졸버에는 Cloudflare의 주소만 보이는 경우, 호스트 입력란에 전체 이름을 넣어 www.example.com.example.com이 만들어진 경우, 이름에 아직 A 레코드가 있어 CNAME을 함께 둘 수 없는 경우, 리졸버가 TTL이 끝날 때까지 이전 응답을 보관하는 경우입니다. 위의 조회는 존의 DNS 호스트, 이름에 있는 레코드, 각 사본의 남은 시간을 보여 줍니다.

CNAME 변경은 반영되기까지 얼마나 걸리나요?

각 리졸버가 마지막으로 가져온 시점부터 이전 레코드의 TTL만큼 걸립니다. 체인의 모든 레코드는 따로 캐시되므로, 최종 주소의 TTL이 몇 초뿐이어도 내가 관리하는 CNAME의 수정은 그 레코드의 사본이 만료되기를 기다립니다. 완전히 새로 만든 이름은 보통 바로 보입니다. 단, 만들기 전에 누군가 그 이름을 질의했다면 예외입니다.

댕글링 CNAME이란 무엇인가요?

대상이 더 이상 존재하지 않는 CNAME입니다: 삭제된 클라우드 앱, 비워진 버킷, 만료된 도메인 등입니다. 다른 사람이 그 대상 이름으로 리소스를 만들 수 있다면 내 서브도메인에서 콘텐츠를 제공할 수 있습니다. 리소스마다 고유한 DNS 이름이 있는 곳에서는 조회 결과가 CNAME이 그대로 담긴 NXDOMAIN으로 나옵니다. 레코드를 삭제하거나 살아 있는 대상을 가리키게 하세요.

CNAME은 몇 개까지 연결할 수 있나요?

DNS에 정해진 최댓값은 없지만, RFC 9460은 연속된 별칭을 8개 이하로 권장합니다. 리졸버는 각자의 한도에서 포기합니다: BIND와 Unbound 11개, PowerDNS 10개, Knot 13개이며, Google과 Cloudflare는 한도를 공개하지 않습니다. 실제 체인은 짧습니다: 저희가 기록한 잘 알려진 사이트 12곳은 별칭을 0개에서 3개까지 사용합니다.

CNAME이 IP 주소를 가리킬 수 있나요?

아니요. CNAME의 값은 호스트 이름이어야 합니다. 192.0.2.1 같은 주소를 CNAME에 입력하면 숫자 레이블 4개로 된 이름으로 읽히는데, 그런 이름은 존재하지 않으므로 별칭이 아무 데도 이어지지 않습니다. 이름이 주소를 가리키게 하려면 대신 IPv4에는 A 레코드를, IPv6에는 AAAA 레코드를 쓰세요.

CNAME은 리다이렉트와 같은 것인가요?

아니요. CNAME은 DNS가 주소를 찾는 위치만 바꿉니다: 브라우저는 주소창에 원래 이름을 유지한 채 서버에 그 이름을 요청하므로, 대상은 내 도메인을 받아들이고 그 인증서를 갖추고 있어야 합니다. 방문자를 다른 URL로 보내려면 웹 서버의 HTTP 301 또는 308 리다이렉트나 DNS 호스트의 포워딩 기능을 쓰세요.

Cloudflare 오류 1014는 무슨 뜻인가요?

CNAME Cross-User Banned: Cloudflare에 있는 이름이 CNAME으로 다른 Cloudflare 계정의 이름을 가리킨다는 뜻입니다. 같은 존 안, 같은 계정의 존 사이, 또는 대상 소유자가 내 호스트 이름을 추가하는 Cloudflare for SaaS를 통해서는 작동합니다. Cloudflare에서 실행되는 SaaS를 가리킨다면, 그 업체에 내 도메인을 사용자 지정 호스트 이름(custom hostname)으로 설정해 달라고 요청하세요.

DKIM 셀렉터에 CNAME을 쓰는 이유는 무엇인가요?

메일 서비스는 DKIM 키를 자기 존에 게시하고 사용자에게 셀렉터가 그 키를 가리키게 해 달라고 요청합니다. 그러면 사용자의 도움 없이 키를 교체할 수 있습니다. Microsoft 365는 selector1·selector2, SendGrid는 s1·s2, Mailchimp는 k2·k3 셀렉터를 씁니다. 이 CNAME은 주소가 아니라 TXT 레코드에서 끝납니다: 자주 쓰는 서브도메인 모드에서 모두 확인할 수 있습니다.

더 많은 DNS 도구