본문 바로가기

DNS 레코드 종류 완벽 정리 – A레코드, CNAME, TXT, MX 뭐가 다른 거야?

반응형

도메인 산 김에 뭔가 설정하려고 들어갔다가 멍때린 적이 한두 번이 아니다.

AWS Route 53이든, 가비아든, 클라우드플레어든... DNS 설정 화면 들어가면 항상 저 알 수 없는 것들이 날 반긴다.

A 레코드, CNAME, TXT, MX, NS, AAAA...

처음엔 대충 "A는 IP 연결하는 거, CNAME은 도메인 연결하는 거겠지~" 하고 감으로 때웠는데, 막상 실무에서 Vercel에 도메인 붙이거나 Google Search Console 인증할 때 헷갈리는 게 한두 개가 아니었다. 그래서 이번 기회에 제대로 정리해봤다.


일단 DNS가 뭔지부터

DNS는 Domain Name System의 약자다. 쉽게 말하면 인터넷 전화번호부 같은 거다.

우리가 google.com을 브라우저에 치면 컴퓨터는 이게 어느 서버 IP인지 모른다. DNS가 그걸 142.250.xxx.xxx 같은 실제 IP로 변환해주는 역할을 한다. 도메인 이름을 사람이 읽기 편하게 쓰고, 실제 통신은 IP로 하는 구조.

그리고 이 DNS 시스템 안에서 "어떤 도메인이 어디로 연결되는지", "이 도메인의 메일 서버는 어디인지" 같은 정보를 담고 있는 게 바로 DNS 레코드다.


A 레코드 (Address Record)

가장 기본이 되는 레코드다. 도메인 → IPv4 주소로 연결해준다.

example.com  →  192.168.0.1

예를 들어 EC2 인스턴스에 직접 도메인 붙이고 싶으면 A 레코드에 그 EC2의 퍼블릭 IP를 넣으면 된다. 단순명쾌하다.

타입: A
이름: @  (또는 example.com)
값: 13.124.xx.xx
TTL: 3600

@는 보통 루트 도메인을 뜻한다. wwwwww.example.com을 가리키는 거고.

근데 IP가 바뀌면 A 레코드도 직접 바꿔줘야 한다. 고정 IP가 아닌 경우엔 관리가 좀 번거롭다.


AAAA 레코드

A 레코드랑 동일한데 IPv6 주소를 쓸 때다. 요즘 IPv6 쓰는 인프라들 많아져서 알아두면 좋다.

example.com  →  2001:0db8:85a3::8a2e:0370:7334

사실 일반적인 설정에선 잘 안 만질 수도 있는데, CDN이나 클라우드 서비스에서 자동으로 추가해주는 경우가 많다.


CNAME 레코드 (Canonical Name Record)

이게 좀 헷갈리는데, 도메인 → 다른 도메인으로 연결해주는 레코드다. IP가 아니라 도메인 이름을 값으로 넣는다.

www.example.com  →  example.com
blog.example.com  →  myapp.vercel.app

실무에서 진짜 많이 쓰는 케이스:

  • Vercel, Netlify, GitHub Pages에 서브도메인 연결할 때
  • CloudFront 배포에 도메인 붙일 때

예를 들어 Vercel에 커스텀 도메인 붙이면 CNAME을 cname.vercel-dns.com 같은 데로 연결하라고 안내해준다. 이러면 Vercel이 IP를 어떻게 바꾸든 간에 CNAME만 살아있으면 자동으로 추적되는 거다.

A 레코드와 CNAME의 차이를 한줄로:

  • A 레코드 = 도메인 → IP (최종 목적지)
  • CNAME = 도메인 → 도메인 (다른 도메인으로 위임)

주의할 점이 있는데, CNAME은 루트 도메인(@, example.com)에는 쓸 수 없다. DNS 표준상 루트 도메인에 CNAME이 있으면 MX나 NS 같은 다른 레코드랑 충돌이 생기기 때문이다. 그래서 Cloudflare 같은 곳에서는 CNAME Flattening이라는 기능으로 이걸 우회해준다.


TXT 레코드 (Text Record)

이름처럼 텍스트 정보를 담는 레코드다. 사람이 읽을 수 없는 복잡한 문자열이 들어가는 경우가 많아서 처음 보면 이게 뭔가 싶다.

주로 쓰이는 용도가 세 가지다.

1. 도메인 소유권 인증

Google Search Console이나 네이버 웹마스터 도구에 도메인 등록할 때 이런 거 추가하라고 한다:

타입: TXT
이름: @
값: google-site-verification=aBcDeFgHiJkL...

이걸 DNS에 추가해두면 구글이 "아 이 사람이 이 도메인 주인이구나" 하고 확인하는 방식이다. DNS는 도메인 주인만 수정할 수 있으니까 이게 곧 소유권 증명이 된다.

2. SPF (Sender Policy Framework)

이메일 발송 관련 설정이다. 내 도메인에서 메일을 보낼 수 있는 서버를 명시해두는 거다.

v=spf1 include:_spf.google.com ~all

이게 없거나 잘못 설정되면 내 도메인에서 보내는 메일이 스팸으로 분류될 수 있다. 메일 서비스 도입할 때 꼭 확인해야 한다.

3. DKIM (DomainKeys Identified Mail)

이것도 이메일 인증인데, 메일 내용이 변조되지 않았다는 걸 검증하기 위한 공개키를 TXT 레코드에 넣어두는 거다. AWS SES나 SendGrid 같은 서비스 쓸 때 추가하라고 안내해준다.

default._domainkey.example.com  →  v=DKIM1; k=rsa; p=MIGfMA0GCSqG...

MX 레코드 (Mail Exchanger Record)

메일 서버 주소를 지정하는 레코드다. @example.com 같은 이메일 주소로 메일 받으려면 MX 레코드가 있어야 한다.

타입: MX
이름: @
우선순위: 10
값: mail.example.com

우선순위(Priority) 숫자가 낮을수록 먼저 시도한다. 여러 개 설정해두면 하나가 죽어도 다음 서버로 받아줘서 안정성이 높아진다.

Google Workspace나 Naver Works 같은 기업 메일 서비스 연결할 때 이 MX 레코드를 수정하는 거다.


NS 레코드 (Name Server Record)

이 도메인의 DNS를 어느 네임서버가 관리하는지 지정하는 레코드다. 가비아에서 도메인 사고 클라우드플레어 DNS 쓰고 싶으면 NS 레코드를 클라우드플레어 네임서버 주소로 바꾸는 거다.

ns1.cloudflare.com
ns2.cloudflare.com

NS 레코드는 보통 도메인 등록기관 콘솔에서 건드리고, DNS 관리 자체는 NS 레코드가 가리키는 서버에서 한다. 계층 구조가 있는 셈이다.


TTL (Time To Live)

레코드 자체는 아닌데 설정할 때 항상 나오는 값이라 짚고 넘어간다. DNS 정보가 캐시에 얼마나 살아있을지를 초 단위로 지정한다.

  • TTL 3600 = 1시간
  • TTL 300 = 5분
  • TTL 86400 = 1일

IP 바꿀 일이 있거나 설정 테스트 중이면 TTL을 낮게 해두면 변경이 빨리 반영된다. 안정화된 이후엔 다시 높여두는 게 네임서버 부하 줄이는 데 좋다.


정리하면

레코드 역할
A 도메인 → IPv4
AAAA 도메인 → IPv6
CNAME 도메인 → 다른 도메인
TXT 텍스트 정보 (인증, 메일 정책)
MX 메일 서버 지정
NS 네임서버 지정

요즘은 Vercel이나 Netlify 같은 플랫폼들이 DNS 설정 가이드를 잘 만들어놔서 그냥 따라하면 되긴 한다. 그래도 저 값들이 왜 들어가는지 모르고 쓰면 뭔가 안 됐을 때 디버깅을 못 하더라.

이번에 개인 도메인에 이것저것 붙이다 보니까 그동안 아무 생각없이 넣던 값들이 이제야 좀 이해가 된다. 특히 TXT 레코드가 이렇게 다양하게 쓰이는 줄은 몰랐는데, 알고 보니 도메인 인증의 핵심이 다 여기 모여있었다.

서버 관련 작업 하는 개발자라면 이 정도는 머릿속에 넣어두면 나중에 분명히 써먹는다.


#DNS #DNS레코드 #A레코드 #CNAME #TXT레코드 #MX레코드 #도메인설정 #DNS설정 #웹개발 #서버설정 #개발자 #네임서버 #Vercel도메인연결 #클라우드플레어 #Route53

반응형