DNS 배포 지식 총정리: NS·A·CNAME·apex 함정까지

배포를 처음 해보면 코드보다 도메인에서 더 오래 막힙니다. 빌드도 통과하고 서버도 떠 있는데, 브라우저에 도메인을 치면 남의 사이트가 뜨거나, 연결이 안 되거나, HTTPS 자물쇠에 빨간 줄이 그어집니다. 원인은 대부분 DNS입니다. 이 글은 배포에 필요한 DNS 지식을 개념부터 실전 설정, 흔한 함정까지 한 번에 정리합니다.

TL;DR#

• DNS는 사람이 읽는 도메인을 서버 IP로 바꿔주는 전화번호부입니다. 도메인 등록(가비아·Cloudflare 등)과 DNS 호스팅(레코드를 실제로 응답하는 곳)은 별개이며, 둘을 잇는 것이 NS 레코드입니다.
• 배포에서 실제로 다루는 레코드는 몇 개뿐입니다: A/AAAA(IP 연결), CNAME(별칭), TXT(소유 확인·메일 인증), MX(메일), CAA(인증서 발급 제한).
• 루트 도메인(apex)에는 CNAME을 쓸 수 없습니다. 이 한 줄이 배포 실패의 절반입니다. 해법은 A 레코드 또는 ALIAS/ANAME/CNAME 플래트닝입니다.
• 바뀐 레코드가 안 보이는 건 대개 TTL과 캐시 때문입니다. '전 세계 전파'라는 표현은 오해를 부릅니다.
• HTTPS 자동 발급도 결국 DNS에 달려 있습니다. 레코드가 맞아야 인증서가 나옵니다.

DNS는 결국 이름을 주소로 바꾸는 일#

컴퓨터는 hooneylog.com을 모릅니다. 아는 것은 76.76.21.21 같은 IP 주소뿐입니다. DNS(Domain Name System)는 이 둘 사이를 이어주는 조회 체계입니다. 브라우저가 도메인을 IP로 바꾸는 과정은 대략 이렇습니다.

1. 브라우저·OS 캐시에 답이 있는지 본다.
2. 없으면 리졸버(보통 통신사나 8.8.8.8 같은 공용 DNS)에 묻는다.
3. 리졸버는 최상위 루트 → TLD(.com) → 도메인의 네임서버 순으로 계층을 따라 내려가며 최종 답을 찾는다.
4. 찾은 IP를 TTL만큼 캐시에 보관한 뒤 돌려준다.

이 구조의 핵심은 계층적 위임입니다. .com을 관리하는 서버는 hooneylog.com의 실제 레코드를 모릅니다. 대신 "그건 저쪽 네임서버에 물어봐"라고 위임합니다. 이 위임의 목적지를 가리키는 것이 바로 NS 레코드입니다.

등록기관과 DNS 호스팅은 다른 것입니다#

배포 초심자가 가장 많이 헷갈리는 지점입니다. 두 역할은 분리돼 있습니다.

• 도메인 등록기관(Registrar): 도메인이라는 '이름의 사용권'을 파는 곳입니다. 가비아, Namecheap, Cloudflare Registrar, Route 53 등. 매년 갱신비를 내는 대상입니다.
• DNS 호스팅(네임서버 운영): 그 도메인의 레코드를 실제로 저장하고 조회에 응답하는 곳입니다. Cloudflare, Route 53, Vercel DNS 등.

한 회사에서 둘 다 할 수도 있고, 등록은 가비아에서 하고 DNS는 Cloudflare로 넘길 수도 있습니다. 이 둘을 잇는 스위치가 네임서버(NS) 설정입니다. 등록기관 관리 화면에서 "네임서버를 Cloudflare 것으로 바꾼다"고 지정하면, 그때부터 그 도메인의 레코드는 Cloudflare에서 관리합니다. 등록기관 쪽 DNS 화면에 레코드를 아무리 넣어도 네임서버가 다른 곳을 가리키고 있으면 그 레코드는 조회되지 않습니다. 배포 설정이 먹지 않을 때 가장 먼저 확인할 곳입니다.

배포에서 실제로 쓰는 레코드 타입#

레코드 타입은 수십 가지지만, 웹 서비스 배포에서 손대는 건 사실상 아래가 전부입니다.

A / AAAA — 도메인을 IP에 연결#

가장 기본입니다. A는 IPv4 주소, AAAA는 IPv6 주소를 가리킵니다.

plain
복사
example.com.      A       76.76.21.21
example.com.      AAAA    2606:4700:3033::ac43:...

배포 플랫폼이 "이 IP로 A 레코드를 걸어라"라고 안내하면 이걸 넣는 것입니다.

CNAME — 다른 이름의 별칭#

CNAME은 "이 이름은 저 이름과 같다"는 별칭입니다. IP가 바뀌어도 대상 호스트명만 따라가므로, 배포 플랫폼이 IP를 유동적으로 관리할 때 흔히 씁니다.

plain
복사
www.example.com.  CNAME   cname.vercel-dns-0.com.

www 같은 서브도메인은 CNAME이 권장됩니다. 단, CNAME이 걸린 이름에는 다른 레코드를 함께 둘 수 없습니다(RFC 1034). 이 규칙이 바로 다음 함정의 원인입니다.

루트 도메인(apex)의 함정과 ALIAS/ANAME#

www 없는 루트 도메인 example.com을 apex(또는 zone apex, naked domain) 라고 부릅니다. apex에는 반드시 SOA와 NS 레코드가 존재해야 합니다. 그런데 CNAME은 "다른 레코드를 함께 두면 안 된다"고 못박습니다. 따라서 apex에는 CNAME을 쓸 수 없습니다. 그래서 example.com을 배포 플랫폼의 호스트명으로 CNAME 걸려고 하면 실패합니다.

해법은 두 가지입니다.

1. A 레코드로 직접 IP 지정: 플랫폼이 안내하는 IP를 apex에 A 레코드로 넣습니다. 예컨대 Vercel은 apex에 A 레코드 사용을 권장하며, 범용 IP는 76.76.21.21이지만 프로젝트마다 최적 IP가 다를 수 있으니 대시보드나 vercel domains inspect example.com으로 실제 권장값을 확인하는 편이 안전합니다.
2. ALIAS / ANAME / CNAME 플래트닝: DNS 호스팅이 apex에서 호스트명을 받아 조회 시점에 IP로 '펼쳐' 응답하는 기능입니다. Cloudflare는 이를 CNAME 플래트닝이라 부르고 모든 요금제에서 apex에 기본 동작합니다. Route 53의 Alias, DNSimple의 ALIAS, DNS Made Easy의 ANAME이 같은 개념입니다. 겉으로는 apex에 CNAME을 건 것처럼 쓰지만 실제 응답은 A/AAAA로 나가므로 RFC를 위반하지 않습니다.

주의할 점 하나. CNAME 플래트닝은 MX(메일) 레코드에는 적용되지 않습니다. MX는 규격상 호스트명을 직접 가리켜야 하므로, 메일까지 쓴다면 별도로 설정해야 합니다.

TXT — 소유 확인과 메일 인증#

TXT는 임의의 텍스트를 담는 레코드입니다. 배포·운영에서 두 용도로 자주 만납니다.

• 도메인 소유 확인: 플랫폼이 "이 값을 TXT로 넣어라"라고 주면, 그 값이 조회되는지로 소유권을 증명합니다. HTTPS 인증서 발급(DNS-01 챌린지)에도 같은 방식이 쓰입니다.
• 메일 인증(SPF·DKIM·DMARC): 메일을 보낸다면 발송 서버를 위조로부터 보호하기 위해 이 세 가지를 TXT로 설정합니다. 설정이 없으면 메일이 스팸함으로 직행하기 쉽습니다.

MX — 메일 라우팅#

MX(Mail eXchange)는 "이 도메인의 메일은 이 서버가 받는다"를 우선순위(숫자가 작을수록 우선)와 함께 지정합니다. 웹만 배포한다면 건드릴 일이 없지만, 회사 메일을 붙인다면 Google Workspace 등이 안내하는 MX 값을 넣습니다. 웹 배포용 A/CNAME 설정과 메일용 MX 설정은 서로 독립적이라는 점만 기억하면 됩니다.

CAA — 인증서 발급 통제#

CAA(Certification Authority Authorization)는 "이 도메인의 SSL 인증서는 지정한 인증기관(CA)만 발급할 수 있다"를 명시합니다. 없으면 어떤 CA든 발급할 수 있습니다. 문제는 CAA를 잘못 걸어두면 배포 플랫폼이 쓰는 CA가 막혀서 HTTPS 인증서 발급이 실패한다는 점입니다. HTTPS가 안 붙는데 원인을 모르겠다면 CAA를 의심해 보세요.

TTL과 '전파'라는 오해#

레코드를 바꿨는데 반영이 안 되는 상황은 거의 항상 캐시 문제입니다. 모든 DNS 응답에는 TTL(Time To Live) 이 붙어 있고, 리졸버들은 그 시간만큼 답을 캐시에 보관합니다. TTL이 3600초면, 이미 옛 값을 받아간 리졸버는 한 시간 동안 옛 값을 돌려줍니다.

흔히 말하는 'DNS 전파'라는 표현은 오해를 부릅니다. 변경 사항이 물결처럼 전 세계로 퍼져 나가는 게 아닙니다. 각 리졸버가 자기 캐시의 TTL이 만료될 때 새로 조회하는 것뿐입니다. 그래서 실전 전략은 이렇습니다.

• 도메인을 옮기거나 IP를 바꿀 예정이면, 하루 전쯤 TTL을 짧게(예: 300초) 낮춰 둔다. 그러면 실제 변경 시 캐시가 빨리 갈립니다.
• 변경 직후 내 화면에서만 옛 값이 보인다면 로컬·브라우저 캐시일 수 있으니, dig로 특정 리졸버에 직접 물어 확인합니다.
• "왜 나는 되는데 친구는 안 되나요?"는 정상입니다. 리졸버마다 캐시 만료 시점이 다르기 때문입니다.

HTTPS 자동 발급도 결국 DNS입니다#

요즘 배포 플랫폼은 Let's Encrypt 같은 CA에서 인증서를 자동 발급·갱신합니다. 이 과정(ACME 프로토콜)은 "당신이 정말 이 도메인의 주인이냐"를 확인하는데, 그 확인이 DNS에 걸립니다.

• HTTP-01 챌린지: 도메인이 플랫폼 서버를 제대로 가리켜야(=A/CNAME이 맞아야) 검증 파일에 접근해 통과합니다. 즉 레코드가 틀리면 인증서도 안 나옵니다.
• DNS-01 챌린지: 지정한 TXT 레코드를 넣어 소유를 증명합니다. 와일드카드 인증서(*.example.com)에 주로 쓰입니다.

그래서 "HTTPS가 안 붙어요"의 원인은 대개 코드가 아닙니다. A/CNAME이 아직 플랫폼을 안 가리키거나, CAA가 CA를 막고 있거나, TTL 때문에 옛 레코드가 캐시에 남아 있는 경우입니다.

실전 배포 체크리스트#

새 도메인을 서비스에 붙일 때 순서대로 확인하면 대부분 한 번에 끝납니다.

1. 네임서버부터 확정: DNS를 어디서 관리할지(Cloudflare/Route 53/플랫폼 DNS) 정하고, 등록기관에서 NS를 그쪽으로 지정한다. 레코드는 그다음이다.
2. apex와 www를 모두 건다: example.com(A 또는 ALIAS)과 www.example.com(CNAME)을 둘 다 설정하고, 한쪽을 다른 쪽으로 301 리다이렉트해 정규 주소를 하나로 통일한다.
3. 소유 확인 TXT 요구가 있으면 넣는다.
4. HTTPS 발급을 기다린다: 레코드가 맞으면 보통 자동으로 붙는다. 안 붙으면 CAA를 확인한다.
5. 메일을 쓴다면 MX·SPF·DKIM·DMARC를 따로 설정한다.

진단은 브라우저 대신 도구로 합니다. 브라우저는 캐시 때문에 거짓말을 하기 때문입니다.

bash
복사
# 특정 리졸버(8.8.8.8)에 A 레코드 직접 조회 — 캐시 우회
dig @8.8.8.8 example.com A +short

# 네임서버가 어디로 위임돼 있는지 확인
dig example.com NS +short

# CNAME/TTL까지 자세히
dig www.example.com CNAME

nslookup example.com 도 간편한 대안입니다. 응답값과 TTL을 눈으로 확인하는 습관이, 막연히 "전파를 기다리는" 시간을 크게 줄여줍니다.

자주 밟는 함정 정리#

• apex에 CNAME: 안 됩니다. A 레코드나 ALIAS/플래트닝을 쓰세요.
• 네임서버를 안 바꾸고 레코드만 수정: 등록기관 DNS에 레코드를 넣었지만 NS가 다른 곳을 가리키면 무효입니다.
• www와 apex 중 하나만 설정: 사용자는 둘 다 칩니다. 둘 다 걸고 하나로 리다이렉트하세요.
• TTL을 안 낮추고 마이그레이션: 옛 IP 캐시가 오래 남습니다. 옮기기 전날 TTL을 내려두세요.
• CAA로 인증서 자멸: CAA를 걸었다면 플랫폼이 쓰는 CA(예: Let's Encrypt)가 포함돼 있는지 확인하세요.
• 메일까지 플래트닝으로 될 거라 착각: MX는 별도입니다.

마치며#

DNS는 배포에서 가장 자주 사람을 막지만, 실제로 다루는 개념은 좁습니다. 이름을 주소로 바꾸는 위임 구조, 등록기관과 DNS 호스팅의 분리, 몇 안 되는 레코드 타입, apex-CNAME 금지, TTL과 캐시. 이 다섯 가지만 손에 익으면 대부분의 "배포는 됐는데 도메인이 안 돼요"는 스스로 진단할 수 있습니다. 막힐 때는 브라우저를 새로고침하는 대신 dig를 먼저 여세요. 도메인은 기다림이 아니라 확인의 문제입니다.