서브도메인 만들기
blog.example.com 처럼 앞에 이름을 붙인 서브도메인을 A 또는 CNAME 레코드로 만드는 방법입니다. 자주 쓰는 구성, 외부 서비스 연결, NS 위임, SSL 인증서와의 관계까지 정리했습니다.
작성
서브도메인은 보유한 도메인 앞에 이름을 덧붙여 만드는 별도의 주소입니다. blog.example.com 을 만들려면 도메인을 새로 등록하는 것이 아니라, 그 도메인의 DNS 존에 blog 라는 이름으로 A 레코드(IP를 가리킬 때) 또는 CNAME 레코드(다른 도메인 이름을 가리킬 때)를 하나 추가하면 됩니다. 도메인 등록 비용은 도메인 단위로 청구되므로 서브도메인을 몇 개 만들어도 추가 등록 비용은 발생하지 않습니다.
서브도메인을 추가하는 곳은 도메인을 등록한 곳이 아니라, 지금 그 도메인이 위임되어 있는 네임서버의 DNS 관리 화면입니다. 레토 네임서버를 쓰고 있다면 대시보드 도메인 상세의 DNS 및 포워딩 탭에 있는 DNS 레코드 카드에서 추가합니다. 각 레코드의 입력 형식은 DNS 레코드 설정에 정리되어 있습니다.
서브도메인은 DNS에서 무엇인가
DNS 이름은 점으로 구분된 계층 구조입니다. blog.example.com 은 example.com 존 안에 있는 blog 라는 이름이고, 그 존에 이름이 등록되어 있는지 여부만으로 존재가 결정됩니다. 레지스트리에 따로 신청하거나 승인받는 절차가 없다는 뜻입니다.
- 만드는 곳
- 도메인이 위임된 네임서버의 DNS 관리 화면
- 필요한 것
- A/AAAA 레코드 또는 CNAME 레코드 1개
- 추가 등록 비용
- 없음 (도메인 단위로 과금)
- 반영 시간
- 해당 레코드의 TTL
한 가지 구분할 점은 example.com 자체입니다. 이 이름은 존의 정점이라 apex 도메인이라고 부르고, 서브도메인과 달리 CNAME을 쓸 수 없는 제약이 있습니다. 자세한 이유와 우회 방법은 와일드카드 레코드와 ALIAS/ANAME에 있습니다.
A 레코드와 CNAME 중 무엇으로 만들까
가리킬 대상이 IP 주소면 A 레코드, 다른 도메인 이름이면 CNAME입니다. 외부 서비스가 연결용 호스트 이름을 알려 주는 경우에는 CNAME이 운영에 유리합니다. 그쪽이 IP를 바꿔도 우리 존을 고칠 필요가 없기 때문입니다.
이름을 정합니다
소문자 영문, 숫자, 하이픈만 쓰고 점은 계층 구분으로만 씁니다.
api-v2는 되지만api_v2는 쓰지 않는 편이 안전합니다.종류를 고릅니다
자체 서버의 고정 IP가 있으면 A(IPv6는 AAAA), 외부 서비스가
something.service-provider.example같은 이름을 안내했으면 CNAME입니다.DNS 관리 화면에서 레코드를 추가합니다
이름 칸에는 보통 앞부분만 넣습니다.
blog.example.com을 만들 때blog만 입력하는 콘솔이 대부분이고, 전체 이름을 넣는 콘솔도 있으니 저장 후 목록에 표시된 이름을 확인하세요.blog.example.co.kr. 3600 IN A 203.0.113.21 api.example.co.kr. 3600 IN CNAME endpoint.service-provider.example.직접 질의해 확인합니다
전파를 기다리기 전에 해당 네임서버에 직접 물어 값이 들어갔는지 봅니다.
dig @ns1.example-dns.com A blog.example.co.kr +noall +answer dig CNAME api.example.co.kr +short확인 방법을 더 자세히 보려면 DNS 조회 도구 사용법을 참고하세요.
서버 쪽에서도 그 이름을 받도록 설정합니다
DNS가 맞아도 웹 서버나 플랫폼이 그 이름을 모르면 엉뚱한 사이트가 열리거나 오류가 납니다. 가상 호스트 이름, 플랫폼의 도메인 목록, 인증서에 새 이름을 추가해야 합니다.
자주 쓰는 구성
| 이름 | 용도 | 보통 쓰는 레코드 |
|---|---|---|
www | 웹사이트의 관례적인 주소 | apex 와 같은 곳을 가리키거나 리다이렉트 |
blog | 블로그 서비스나 CMS | 외부 서비스면 CNAME |
api | API 서버, 웹과 분리해 운영 | A 또는 로드밸런서 CNAME |
shop | 쇼핑몰 솔루션 | 솔루션이 안내하는 CNAME |
staging, dev | 검수와 개발 환경 | A 또는 CNAME, 검색 노출은 차단 |
mail, webmail | 메일 서버나 웹메일 접속 주소 | A 또는 메일 서비스가 안내하는 CNAME |
mail 에는 주의할 점이 있습니다. 메일을 어느 서버가 받을지 정하는 것은 mail 서브도메인이 아니라 도메인의 MX 레코드입니다. mail.example.com 은 사람이 웹메일에 접속하는 주소일 뿐이므로, 메일 수신은 SPF, DKIM, DMARC 설정과 MX 레코드로 따로 구성해야 합니다.
검수용 이름은 검색엔진에 노출되거나 외부에서 접근되면 곤란한 경우가 많습니다. DNS에는 접근 제어 기능이 없으므로, 서버 단계의 인증이나 IP 제한으로 막아야 합니다.
외부 서비스와 다른 서버에 붙이기
서브도메인별로 목적지를 따로 두면 서비스마다 다른 제공자를 쓸 수 있습니다. 본 사이트는 사내 서버에 두고 쇼핑몰과 블로그만 외부 솔루션에 맡기는 구성이 흔합니다.
- 외부 서비스가 안내한 값을 그대로 넣습니다. 비슷해 보이는 다른 호스트 이름으로 바꾸면 연결되지 않습니다
- 서비스 쪽 관리 화면에도 그 서브도메인을 등록합니다. DNS만 바꾸면 절반만 끝난 상태입니다
- 소유 확인용 TXT 값을 같이 요구하는 서비스가 많습니다. CNAME을 건 이름에는 TXT를 함께 둘 수 없으니 확인 레코드의 이름을 잘 보세요
- 서비스를 해지할 때는 레코드를 함께 지웁니다. 남겨 두면 남이 그 이름을 가져가는 위험이 생깁니다
마지막 항목은 실제로 사고가 자주 나는 부분입니다. 외부 서비스를 해지했는데 그 서비스를 가리키는 CNAME이 남아 있으면, 제3자가 그 서비스에서 같은 호스트 이름을 선점해 우리 서브도메인으로 임의의 페이지를 띄울 수 있습니다. 쓰지 않는 서브도메인 레코드는 정리하는 것이 원칙입니다. 플랫폼별 연결 값은 외부 서비스 연결하기에 있습니다.
하위 존을 위임하기
서브도메인 아래의 DNS 관리 권한을 다른 팀이나 다른 네임서버에 넘길 수도 있습니다. 그 이름에 NS 레코드를 두면 해당 이름 이하의 질의는 지정한 네임서버가 답합니다.
dev.example.co.kr. 3600 IN NS ns1.dev-dns.example.
dev.example.co.kr. 3600 IN NS ns2.dev-dns.example.
이렇게 하면 api.dev.example.co.kr 같은 이름은 상위 존이 아니라 위임받은 네임서버에서 관리합니다. 개발 환경을 개발팀이 직접 운용하거나, 사내 시스템용 존을 분리할 때 씁니다.
SSL 인증서와의 관계
인증서는 도메인 단위가 아니라 이름 단위로 검증됩니다. example.com 용 인증서로 blog.example.com 을 열면 브라우저가 경고를 띄웁니다. 선택지는 두 가지입니다.
| 상황 | 권장 | 이유 |
|---|---|---|
| 서브도메인이 몇 개로 고정 | 이름을 여러 개 넣은 인증서 | HTTP 검증으로 자동 갱신이 쉽고 발급 이력 추적도 단순 |
| 이름이 계속 늘거나 미리 모름 | 와일드카드 인증서 | 한 장으로 한 단계 아래 이름을 모두 덮음 |
와일드카드 인증서 *.example.com 은 한 단계 아래만 덮습니다. a.b.example.com 은 포함되지 않으므로 두 단계 아래 이름을 쓸 계획이면 별도 인증서나 추가 이름이 필요합니다. 와일드카드는 DNS 방식 검증만 허용되는 등 운영 조건도 다르니, 발급과 갱신 절차는 SSL 인증서 적용하기를 먼저 읽어 주세요.
새 이름을 추가했는데 사이트가 열리지 않는다면 원인은 DNS, 서버의 이름 설정, 인증서 세 곳 중 하나입니다. 순서대로 좁히는 방법은 웹사이트가 열리지 않을 때에 정리되어 있습니다.
자주 묻는 질문
도메인 등록 비용은 example.com 같은 도메인 하나를 기준으로 청구되고, 그 아래 서브도메인은 보유한 도메인의 DNS 존에 레코드를 추가하는 것이므로 별도 등록 절차나 등록 비용이 없습니다. 필요한 만큼 만들고 지울 수 있습니다. 다만 서브도메인이 가리키는 서버나 외부 서비스의 이용료는 그 서비스의 정책을 따릅니다.
DNS 표준에는 개수 제한이 없고, 실무에서는 쓰는 DNS 호스팅이 존 하나에 허용하는 레코드 수가 상한이 됩니다. 레토 네임서버의 존당 레코드 수 제한은 별도 확인이 필요합니다. [확인 필요] 수백 개 단위로 늘어날 예정이라면 와일드카드나 하위 존 위임을 먼저 검토하세요.
가능합니다. 서브도메인마다 레코드 값을 따로 두기 때문에 example.com 은 사내 서버, shop.example.com 은 외부 쇼핑몰, blog.example.com 은 블로그 서비스로 각각 보낼 수 있습니다. 이름마다 독립적으로 동작하므로 한쪽 서비스를 옮겨도 다른 쪽은 영향을 받지 않습니다.
인증서는 이름 단위로 검증되므로 각 서브도메인이 인증서에 포함되어 있어야 합니다. 이름이 몇 개로 고정되어 있으면 인증서 한 장에 이름을 여러 개 넣는 방식이 운영하기 쉽고, 이름이 계속 늘어난다면 와일드카드 인증서를 검토합니다. 호스팅 플랫폼이 자동 발급해 주는 환경이라면 도메인을 추가 등록하는 순간 자동으로 처리되는 경우가 많습니다.
네, www 는 관례상 많이 쓰는 이름일 뿐 기술적으로는 다른 서브도메인과 완전히 같습니다. 따라서 www 에도 A 또는 CNAME 레코드를 따로 넣어야 하고, 넣지 않으면 www 주소만 열리지 않습니다. apex 와 www 중 한쪽을 대표로 정하고 나머지는 리다이렉트로 받는 구성이 일반적입니다.
관련 가이드
- DNS 레코드 설정 (A, AAAA, CNAME, MX, TXT, SRV)A, AAAA, CNAME, MX, TXT, SRV 레코드가 각각 무엇을 하고 어떤 값을 넣어야 하는지 예시로 정리했습니다. 루트 도메인에 CNAME을 걸 수 없는 이유와 TTL 기준도 함께 다룹니다.
- 와일드카드 레코드와 ALIAS/ANAME와일드카드 레코드가 어떤 이름을 잡고 어떤 이름을 놓치는지, 명시적 레코드가 우선하는 규칙과 와일드카드의 위험을 정리했습니다. apex에 CNAME을 쓸 수 없는 제약을 ALIAS, ANAME, CNAME 플래트닝이 어떻게 우회하는지도 함께 다룹니다.
- SSL 인증서 적용하기사이트에 HTTPS를 켜기 위한 SSL/TLS 인증서 적용 방법입니다. 도메인 소유 검증 방식, 무료 자동 발급 인증서, 와일드카드 인증서, 갱신과 만료 모니터링, CAA 레코드까지 순서대로 정리했습니다.
- 외부 서비스에 도메인 연결하기Vercel, Netlify, GitHub Pages, Cloudflare, AWS 같은 외부 서비스에 회사 도메인을 연결하는 방법입니다. A와 CNAME 중 무엇을 쓸지, apex와 www를 어떻게 나눌지, 값을 어디서 복사해 어떻게 확인하는지 정리했습니다.