DNS 레코드 타입 종류 총정리 — A·AAAA·CNAME·MX·TXT·NS, 실무에서 진짜 쓰는 6가지

 

DNS 레코드 타입은 도메인을 한 번이라도 직접 운영해 본 사람이라면 반드시 마주치는 개념입니다. A, AAAA, CNAME, MX, TXT, NS — 이름만 보면 뭐가 뭔지 감이 잘 안 오지만, 각각 도메인 주소를 IP에 연결하고, 메일을 올바른 서버로 보내고, 도메인 소유권을 증명하는 식으로 맡은 일이 전부 다릅니다. 이 글에서는 가장 자주 쓰이는 DNS 레코드 6종이 실제로 무슨 일을 하는지, 그리고 현장에서 이걸 잘못 건드렸을 때 어떤 사고가 터지는지를 정리해 보겠습니다.

 

 

"CNAME이랑 A 레코드 차이가 대체 뭐예요?"
"메일이 갑자기 안 와요. 이거 DNS 문제인가요?"
"인증서 자동 갱신하려는데 CNAME 지우지 말라는 게 무슨 소리죠?"
"도메인은 샀는데 사이트가 안 열려요. 뭘 설정해야 하나요?"

 

 

사실 DNS 레코드는 좀 얄궂은 구석이 있습니다. 한 번 제대로 설정해 두면 그 뒤로는 몇 년이고 건드릴 일이 없어요. 그러다 보니 메커니즘은 귀동냥으로 알고 있어도 막상 손으로 직접 만져 본 경험은 의외로 적은 경우가 많습니다. 저도 그랬습니다. "A 레코드는 도메인을 IP에 연결하는 거지" 정도는 알고 있었는데, 5년 차쯤 AWS 인프라를 직접 맡게 되고 서버를 옮기는 작업을 하면서 생각보다 헤맸어요. 개념을 안다는 것과 직접 해 봤다는 건 다른 얘기더군요.

그래서 이 글은 단순 용어 정리에서 그치지 않고, "이 레코드를 잘못 만지면 무슨 일이 벌어지나"까지 같이 다룹니다. 도메인을 처음 연결해 보는 분, 메일이 안 가서 답답한 분, AWS·클라우드 환경에서 인증서나 서버 이전을 앞둔 분께 도움이 될 겁니다. 앞서 포트(Port) 글과 묶이는 네트워크 기초 시리즈의 연장선이기도 합니다.

📋 목차

1. DNS란 무엇인가 — 도메인을 IP로 바꾸는 번역기
2. DNS 레코드 타입 종류 6가지 한눈에 보기
3. A 레코드 — 도메인을 IPv4 주소로
4. AAAA 레코드 — 도메인을 IPv6 주소로
5. CNAME 레코드 — 별칭, 그리고 인증서 갱신의 함정
6. MX 레코드 — 메일이 어디로 갈지 정하는 표지판
7. TXT 레코드 — SPF·DKIM·DMARC와 도메인 인증
8. NS 레코드와 네임서버 — DNS는 누가 관리하나
9. DNS 레코드 설정 시 자주 터지는 사고들

1. DNS란 무엇인가 — 도메인을 IP로 바꾸는 번역기

우리가 브라우저에 devwar.tistory.com을 입력하면, 컴퓨터는 사실 그 글자만으로는 아무것도 못 합니다. 실제로 통신을 하려면 211.231.99.xxx 같은 숫자 주소(IP)가 필요해요. 사람이 외우기 좋은 이름을, 기계가 알아듣는 숫자로 바꿔 주는 번역기 — 그게 DNS(Domain Name System)입니다. 흔히 전화번호부에 비유하는데, 이름(도메인)으로 찾으면 전화번호(IP)를 알려 주는 셈이죠.

지금은 너무 당연하게 쓰지만, DNS가 없던 시절엔 컴퓨터마다 hosts라는 파일에 "이 이름은 이 IP"라는 목록을 일일이 적어 두고 공유했습니다. 인터넷에 연결된 기계가 몇 대 안 되던 시절 얘기예요. 호스트가 폭발적으로 늘면서 그 방식이 한계에 부딪혔고, 1980년대에 이름을 계층적으로 나눠 관리하는 DNS 구조가 등장합니다. 우리가 지금 다룰 레코드들은 그 거대한 번역 시스템 안에 들어가는 항목 하나하나라고 보면 됩니다.

 

 

💡 도메인 등록 ≠ DNS 설정

도메인을 구매한 곳(등록기관)과

그 도메인의 DNS 레코드를 실제로 관리하는 곳(DNS 호스팅)은 다를 수 있습니다.

"도메인은 샀는데 사이트가 안 열린다"는 대부분 레코드를 아직 안 넣었거나,

DNS를 어디서 관리할지 위임(NS)이 안 된 경우입니다.

 

2. DNS 레코드 타입 종류 6가지 한눈에 보기

세부 설명에 들어가기 전에, 6개를 한 표로 먼저 훑어 두면 뒤 내용이 훨씬 잘 붙습니다.

반응형

레코드	하는 일	값의 예시
A	도메인 → IPv4 주소 연결	192.0.2.10
AAAA	도메인 → IPv6 주소 연결	2001:db8::1
CNAME	도메인 → 다른 도메인(별칭)	www → example.com
MX	메일을 받을 서버 지정	10 mail.example.com
TXT	자유 텍스트(인증·메일 보안 등)	v=spf1 include:...
NS	이 도메인의 DNS를 관리하는 서버	ns1.provider.com

3. A 레코드 — 도메인을 IPv4 주소로

A 레코드는 가장 기본이자 가장 오래된 레코드입니다. 도메인 이름을 IPv4 주소 하나에 연결해 줍니다. example.com → 192.0.2.10 이런 식이죠. 사이트가 안 열린다는 문의의 상당수는 결국 A 레코드가 없거나, 엉뚱한 IP를 가리키고 있는 경우입니다.

여기서 'A'는 Address의 약자입니다. 그리고 이 A 레코드가 가리키는 건 32비트 IPv4 주소예요. 서버를 옮길 때 가장 직접적으로 만지는 게 바로 이 레코드입니다. 새 서버의 IP로 A 레코드 값만 바꾸면 트래픽이 새 서버로 흘러가야 하는데 — 문제는 그게 '즉시'가 아니라는 점입니다. 이 얘기는 뒤 함정 섹션에서 제 경험과 함께 풀겠습니다.

4. AAAA 레코드 — 도메인을 IPv6 주소로

AAAA 레코드는 하는 일은 A와 똑같습니다. 도메인을 IP에 연결해요. 다만 IPv4가 아니라 IPv6 주소를 가리킨다는 점이 다릅니다. 이름이 'A'가 네 개인 이유가 재미있는데, IPv4 주소가 32비트인 반면 IPv6 주소는 128비트로 정확히 네 배라서 A를 네 번 붙였다는 설명이 흔히 통용됩니다.

IPv4 주소가 고갈 문제로 한계에 부딪히면서 그 대안으로 나온 게 IPv6이고, AAAA는 거기에 대응하는 레코드입니다. 한 도메인에 A와 AAAA를 둘 다 둘 수 있고, 그러면 IPv6를 지원하는 환경은 AAAA를, 아니면 A를 쓰게 됩니다. 일반적인 웹사이트 운영에서는 A만으로도 충분한 경우가 많지만, IPv6 환경이 늘면서 AAAA를 함께 두는 사례도 자연스럽게 많아지고 있습니다.

5. CNAME 레코드 — 별칭, 그리고 인증서 갱신의 함정

CNAME(Canonical Name)은 도메인을 또 다른 도메인에 연결하는 '별칭' 레코드입니다. 예를 들어 www.example.com을 example.com으로 가리켜 두면, www로 들어온 요청이 결국 같은 곳을 보게 됩니다. IP가 바뀌어도 원본 도메인의 A 레코드만 고치면 되니, 여러 서브도메인을 한 곳으로 모을 때 편리합니다.

그런데 CNAME에는 유명한 제약이 하나 있습니다. 루트 도메인(example.com 자체, 흔히 zone apex라고 부릅니다)에는 원칙적으로 CNAME을 걸 수 없어요. 루트에는 MX, NS 같은 다른 레코드가 함께 존재해야 하는데, CNAME은 "이 이름의 모든 건 저쪽을 보라"는 의미라서 다른 레코드와 충돌하기 때문입니다. 그래서 클라우드 업체들은 이 문제를 우회하려고 ALIAS나 ANAME 같은 자체 레코드를 따로 제공하기도 합니다.

 

 

📌 AWS에서 인증서 자동 갱신하려면 CNAME을 지우지 마세요

AWS의 인증서 서비스(ACM)에서 DNS 방식으로 도메인 소유권을 검증하면,

검증용 CNAME 레코드를 하나 넣으라고 안내합니다.

여기서 흔히 하는 실수가, 인증서가 한 번 발급되고 나면 그 CNAME을 "이제 끝났겠지" 하고 지우는 겁니다.

그러면 나중에 인증서 자동 갱신이 조용히 실패합니다.

ACM은 갱신 시점에 그 CNAME이 여전히 살아 있는지를 다시 확인하거든요.

검증용 CNAME은 인증서를 쓰는 동안 계속 남겨 두는 게 맞습니다.

 

 

저는 이걸 알고 있던 편이라 다행이었는데, 주변에서 "왜 갑자기 인증서가 만료됐지?" 하고 당황하는 경우를 종종 봤습니다. 한 번 넣고 잊어버리는 레코드일수록 이렇게 뒤늦게 발목을 잡습니다.

6. MX 레코드 — 메일이 어디로 갈지 정하는 표지판

MX(Mail eXchange) 레코드는 "이 도메인으로 온 메일은 어느 서버가 받아라"를 지정합니다. example.com으로 보낸 메일이 실제로 도착할 메일 서버를 가리키는 거죠. 웹사이트(A 레코드)와 메일 서버(MX 레코드)는 서로 별개라, 사이트는 멀쩡한데 메일만 안 가는 상황이 충분히 생길 수 있습니다.

MX 레코드에는 우선순위 숫자가 붙습니다. 10 mail1.example.com, 20 mail2.example.com 이런 식인데, 숫자가 작을수록 우선순위가 높습니다. 평소엔 10번 서버로 가다가 그쪽이 죽으면 20번으로 넘어가는 식의 이중화에 쓰입니다. 구글 워크스페이스나 외부 메일 서비스를 쓸 때, 안내받은 MX 값을 우선순위까지 정확히 넣지 않아서 메일이 새는 사고가 종종 나옵니다.

7. TXT 레코드 — SPF·DKIM·DMARC와 도메인 인증

TXT 레코드는 원래 도메인에 자유로운 텍스트를 붙여 두기 위한, 가장 융통성 있는 레코드입니다. 그런데 바로 그 융통성 덕분에 지금은 도메인 소유권 증명과 메일 보안의 핵심으로 자리 잡았습니다. "이 도메인이 우리 것임을 증명하라"며 특정 문자열을 TXT에 넣으라고 요구하는 서비스들, 다들 한 번쯤 보셨을 겁니다.

특히 메일 쪽에서 TXT의 역할이 부쩍 커졌습니다. 발신자 위조와 스팸을 막기 위한 SPF, DKIM, DMARC가 모두 TXT 레코드(또는 그에 준하는 형태)로 도메인에 게시됩니다. SPF는 "내 도메인 이름으로 메일을 보낼 수 있는 서버는 이것들뿐"이라고 선언하고, DKIM은 메일에 위조 방지 서명을 붙이며, DMARC는 인증에 실패한 메일을 어떻게 처리할지를 정합니다.

 

 

📌 2026년 현재, 이건 선택이 아니라 사실상 강제

구글과 야후는 2024년 2월부터 하루 5,000통 이상을 보내는 대량 발송자에게

SPF·DKIM·DMARC 설정을 요구하기 시작했습니다.

 

2025년 11월부터는 조건을 못 갖춘 메일에 일시 지연이 아니라 영구 거부(550)가 적용되고,

2025년 5월부터는 마이크로소프트(Outlook)도 같은 대열에 합류했습니다.

예전에는 "권장 사항"이던 게 지금은 사실상 의무가 된 셈입니다.

 

 

저는 CORS가 권장에서 사실상 강제로 넘어가던 시기를 현장에서 겪어 봤는데, TXT 기반 메일 인증도 비슷한 길을 가고 있다는 인상을 받습니다. 처음엔 "안 하면 좀 불리한 정도"였다가, 어느 순간 "안 하면 아예 안 되는" 쪽으로 분위기가 굳어지는 거죠.

8. NS 레코드와 네임서버 — DNS는 누가 관리하나

NS(Name Server) 레코드는 조금 메타한 레코드입니다. "이 도메인의 DNS 레코드들을 실제로 관리하는 네임서버가 누구인지"를 가리키거든요. 앞서 본 A, MX, TXT 같은 레코드가 전화번호부 안의 '항목'이라면, NS는 "이 도메인의 전화번호부는 저쪽 책장에 있다"고 알려 주는 표지판에 가깝습니다.

 

 

💡 DNS와 네임서버는 같은 말인가요?

흔히 헷갈리는데, 엄밀히 따지면 다릅니다.

DNS(Domain Name System)는

도메인을 IP로 바꾸는 체계 전체를 가리키는 말이고,

네임서버는 그 DNS 질의에 실제로 답을 돌려주는 서버입니다.

시스템이 DNS, 그 시스템을 굴리는 일꾼이 네임서버인 셈이죠.

다만 NS 레코드 자체가 글자 그대로 'Name Server'이고,

한국 호스팅에서 "네임서버 설정"이라고 하면 사실상

"이 도메인 DNS를 어디서 관리할지 위임하는 일"을 뜻하다 보니,

실무에서는 두 단어가 거의 같은 의미로 섞여 쓰입니다.

 

 

도메인을 등록기관에서 산 다음, 그 도메인의 DNS를 어디서 관리할지(예: 특정 클라우드의 DNS 서비스) 정하고 NS를 그쪽으로 위임해야 비로소 레코드 설정이 효력을 갖습니다. NS가 엉뚱한 데를 가리키고 있으면, A든 MX든 아무리 정성껏 넣어도 적용이 안 됩니다. 도메인을 새 DNS로 옮길 때 흔히 막히는 지점이 바로 이 네임서버 위임 단계입니다.

9. DNS 레코드 설정 시 자주 터지는 사고들

이제 제가 실제로 겪었거나 옆에서 본 사고들을 정리해 보겠습니다. 레코드 정의보다 사실 이쪽이 더 쓸모 있을지도 모르겠네요.

전파 지연(TTL)을 안 믿고 패닉에 빠지는 경우. 서버를 옮기면서 A 레코드 IP를 새 값으로 바꾸면, 머릿속으로는 '바로 바뀌겠지' 싶습니다. 그런데 DNS에는 TTL(Time To Live)이라는 캐시 유효 시간이 있어서, 전 세계 곳곳에 캐시된 옛 값이 그 시간이 지날 때까지 살아 있습니다. 저도 AWS로 서버 이전을 하면서 이걸 머리로는 알았는데, 막상 "왜 누구는 새 서버로 가고 누구는 옛 서버로 가지?" 하는 상황을 직접 겪으니 잠깐 당황했습니다. 메커니즘을 아는 것과 그 어정쩡한 과도기를 직접 견뎌 보는 건 정말 다른 경험이더군요. 이전 작업 전에 TTL을 미리 짧게 줄여 두면 전환이 훨씬 부드럽습니다.

루트 도메인에 CNAME을 욱여넣으려다 막히는 경우. 5번에서 다룬 zone apex 제약이 실전에서 그대로 튀어나옵니다. 루트에 CNAME이 거부되면 ALIAS/ANAME 같은 대체 레코드가 있는지 확인하는 게 정석입니다.

인증서 검증용 CNAME을 지워서 갱신이 깨지는 경우. 역시 앞서 강조한 그 함정입니다. "발급 끝났으니 청소하자"가 오히려 사고를 부릅니다.

사이트는 되는데 메일만 안 가는 경우. A와 MX가 별개라는 걸 놓치면 원인 찾는 데 한참 헤맵니다. 메일 문제는 MX부터, 그다음 TXT(SPF/DKIM/DMARC)를 봐야 합니다.

돌이켜보면 DNS는 "어렵다기보다 자주 안 해 봐서 낯선" 영역에 가깝습니다. 개념 자체는 위 표 한 장으로 정리될 만큼 단순한데, 한 번 설정하면 오래 안 건드리니 손에 익을 틈이 없는 거죠. 그래서 닥쳤을 때 한 번 제대로 정리해 두면, 다음에 같은 상황이 와도 훨씬 덜 당황하게 됩니다.

자주 묻는 질문

A 레코드와 CNAME, 언제 뭘 써야 하나요?

최종 목적지가 고정된 IP면 A 레코드, 다른 도메인을 따라가게 하고 싶으면 CNAME입니다. 단, 루트 도메인에는 CNAME을 쓸 수 없으니 그 경우엔 A(또는 클라우드의 ALIAS류)를 씁니다.

DNS 설정을 바꿨는데 왜 바로 반영이 안 되나요?

TTL이라는 캐시 시간 때문입니다. 변경 전에 TTL을 짧게 낮춰 두면 전환이 빨라지고, 큰 변경을 앞뒀다면 미리 줄여 두는 편이 안전합니다.

메일이 자꾸 스팸으로 가거나 거부됩니다. DNS 문제일 수 있나요?

가능성이 높습니다. TXT 레코드로 게시하는 SPF·DKIM·DMARC가 제대로 설정돼 있는지 먼저 확인해 보세요. 2026년 현재 주요 메일 서비스들은 이 설정이 없으면 대량 발송 메일을 거부하기도 합니다. 다만 발송 환경마다 구성이 달라 단정하긴 어려우니, 본인 도메인 상황에 맞춰 점검하는 게 좋습니다.

DNS와 네임서버는 같은 말인가요?

엄밀히는 다릅니다. DNS는 도메인을 IP로 바꾸는 체계 전체를 뜻하고, 네임서버는 그 질의에 실제로 답하는 서버입니다. 다만 NS 레코드가 곧 Name Server이고, 한국 호스팅에서 "네임서버 설정"이 사실상 DNS 위임을 가리키다 보니 실무에서는 거의 같은 의미로 쓰입니다.

도메인을 샀는데 사이트가 안 열려요.

먼저 네임서버(NS)가 DNS를 관리할 곳으로 제대로 위임됐는지, 그다음 A(또는 AAAA) 레코드가 서버 IP를 가리키는지를 확인하세요. 둘 중 하나라도 비어 있으면 사이트가 안 뜹니다.

마무리

DNS 레코드 6종을 한 줄로 줄이면 이렇습니다. A·AAAA는 도메인을 IP에 연결하고, CNAME은 별칭을 만들고, MX는 메일을 라우팅하고, TXT는 소유권과 메일 보안을 증명하고, NS는 이 모든 레코드를 누가 관리하는지 가리킵니다. 정의만 보면 단순하지만, 한 번 설정하면 오래 안 건드리는 특성 탓에 막상 닥치면 낯설게 느껴지는 영역이기도 합니다.

제가 AWS 인프라를 맡고 서버를 옮기면서 배운 건, 결국 직접 한 번 만져 봐야 손에 남는다는 것이었습니다. 귀동냥으로 안다고 생각했던 것들이 실전에서는 의외로 미끄러지더군요. 다음에 도메인을 연결하거나 인증서를 갱신하거나 메일 설정을 손볼 일이 생기면, 이 글의 표 한 장만 다시 펴 봐도 한결 수월할 겁니다. 포트 편과 함께 네트워크 기초를 다지는 데 보탬이 되길 바랍니다.

📚 함께 보면 좋은 글

꼭 외워야 할 TCP/UDP 포트 번호 모음 - 13년 차 개발자가 후배에게 외우라고 하는 포트들

chmod 권한 숫자(644·755·777) 더는 검색하지 마세요 - 리눅스 파일 권한표 총정리