DNS 레코드 종류 총정리: A·AAAA·CNAME·MX·TXT·NS

도메인을 처음 등록하고 DNS 관리 화면을 열면 A, AAAA, CNAME, MX, TXT 같은 낯선 약어가 한꺼번에 쏟아진다. 겁먹을 필요는 없다. DNS 레코드는 결국 전부 같은 문장 구조다 — "이 이름을 물어보면, 이 값을 돌려줘라". 타입은 그 값이 무엇인지(IP인지, 다른 이름인지, 메일 서버인지, 텍스트인지)를 구분하는 표시일 뿐이다.

이 글은 실무에서 실제로 만지게 되는 9가지 레코드 타입을 진짜 값 예시와 함께 하나씩 설명하고, 마지막에는 작은 회사 도메인 하나가 어떤 레코드 조합으로 완성되는지를 한 줄씩 따라가며 보여준다. 읽는 중에 궁금한 도메인이 생기면 DNS 조회 도구에 넣어 실제 레코드를 바로 확인하면서 따라오면 이해가 훨씬 빠르다.

주소 레코드: A, AAAA, 그리고 별명인 CNAME

가장 기본은 이름을 IP 주소로 바꾸는 레코드다. A 레코드는 IPv4 주소를, AAAA 레코드는 IPv6 주소를 가리킨다(A가 32비트, AAAA는 그 4배인 128비트라서 A를 네 번 쓴 이름이다).

• A — example.com → 93.184.216.34 (IPv4)
• AAAA — example.com → 2606:2800:21f:cb07:6820:80da:af6b:8b2c (IPv6)
• CNAME — www.example.com → example.com (다른 이름으로 위임)

CNAME은 IP가 아니라 "정답은 저 이름한테 물어봐라"라고 다른 이름을 가리키는 별명(alias) 레코드다. 호스팅 업체 주소가 바뀌어도 내 레코드를 고칠 필요가 없어 편리하지만, 두 가지 강한 제약이 있다.

• 다른 레코드와 공존 불가— 어떤 이름에 CNAME을 걸면 그 이름에는 다른 타입 레코드를 함께 둘 수 없다. CNAME은 "모든 질문을 저쪽으로 넘긴다"는 뜻이라, 같은 이름에 MX나 TXT가 있으면 서로 모순이 되기 때문이다.
• 루트 도메인(apex)에는 금지 — example.com 자체에는 반드시 SOA와 NS 레코드가 있어야 하는데, 위 규칙 때문에 CNAME과 공존할 수 없다. 그래서 www에는 CNAME을 쓰고, 루트에는 A 레코드(또는 DNS 업체가 제공하는 ALIAS/ANAME/CNAME flattening 같은 확장 기능)를 쓰는 것이 표준 패턴이다.

메일 레코드: MX와 TXT(SPF·DKIM·소유권 확인)

MX(Mail eXchanger) 레코드는 "이 도메인으로 온 메일을 어느 서버가 받는가"를 정한다. 값은 우선순위 숫자 + 서버 이름 두 부분으로 되어 있다. 예: 10 aspmx.l.google.com. 숫자가 작을수록 먼저 시도하고, 같은 숫자끼리는 부하가 분산된다. 중요한 규칙 하나 — MX의 값은 반드시 이름(호스트명)이어야 하며 IP를 직접 쓰면 안 된다(그 이름은 다시 A/AAAA로 풀려야 하고, CNAME이어서도 안 된다).

TXT 레코드는 임의의 텍스트를 담는 만능 주머니다. 원래는 메모용이었지만 지금은 메일 인증과 서비스 소유권 확인의 핵심 통로가 됐다.

• SPF — "v=spf1 include:_spf.google.com ~all" : 이 도메인 이름으로 메일을 보낼 수 있는 서버 목록.
• DKIM — selector1._domainkey 이름에 공개키를 담아, 메일 서명 검증에 사용.
• 소유권 확인 — "google-site-verification=abc123..." : 구글 서치콘솔 같은 서비스가 "이 도메인의 주인이 맞는지" 확인하는 값.

운영·보안 레코드: NS, SOA, CAA, PTR

자주 편집하지는 않지만 도메인의 뼈대를 이루는 레코드들이다.

• NS(Name Server) — example.com → ns1.dnshost.com. : 이 도메인의 레코드를 어느 네임서버가 관리하는지(위임). 호스팅이나 DNS 업체를 옮길 때 바꾸는 레코드가 바로 이것이며, 전 세계 반영이 가장 오래 걸린다.
• SOA(Start of Authority) — 존(zone)마다 정확히 1개. 주 네임서버, 관리자 메일, 그리고 serial(존 버전 번호 — 레코드를 수정할 때마다 증가), refresh/retry/expire 같은 보조 네임서버 동기화 주기를 담는다. 직접 만들 일은 거의 없고 DNS 업체가 자동 관리한다.
• CAA(Certification Authority Authorization) — 0 issue "letsencrypt.org" : 이 도메인의 SSL 인증서를 어느 인증기관(CA)만 발급할 수 있는지 제한한다. 없으면 아무 CA나 발급 가능. 보안을 한 단계 올리는 저비용 설정이다.
• PTR(Pointer) — 34.216.184.93.in-addr.arpa → example.com: 역방향 조회, 즉 "이 IP의 이름은 무엇인가". 일반 DNS 관리 화면이 아니라 IP를 소유한 ISP·호스팅 업체 쪽에서 설정한다. 메일 서버를 직접 운영한다면 PTR이 없을 때 스팸 판정을 받기 쉽다.

레코드 타입 한눈에 보기

TTL은 리졸버가 캐시를 유지하는 시간(초)이다. 값을 바꿀 예정이라면 미리 TTL을 낮춰 두는 게 정석이며, 변경 순서 전체는 DNS 변경 체크리스트로 빠짐없이 점검할 수 있다.

실전 예시: 작은 회사 도메인의 전체 레코드 세트

acme-store.co.kr라는 가상의 쇼핑몰이 웹은 클라우드 호스팅, 메일은 구글 워크스페이스를 쓴다고 하자. 실제로 필요한 레코드 전체는 이 정도다.

줄별로 읽어 보자. 방문자가 www.acme-store.co.kr를 입력하면 CNAME이 루트로 넘기고, 루트의 A 레코드가 203.0.113.10을 돌려줘 웹 서버에 연결된다. 누군가info@acme-store.co.kr로 메일을 보내면 MX가 구글 서버를 알려주고, 반대로 이 도메인이 보낸 메일은 수신 측이 SPF TXT와 DKIM 키로 진짜인지 검증한다. 소유권 확인 TXT는 서치콘솔 연결에, CAA는 인증서 발급 통제에 쓰인다. 루트에 A·MX·TXT가 여러 개 공존하는 것을 보면, 왜 루트에 CNAME을 걸 수 없는지도 자연스럽게 이해된다.

이 구성을 실제 도메인에 적용했다면 DNS 조회로 각 타입이 의도한 값으로 응답하는지 확인하고, 변경 직후라면 DNS 전파 확인으로 전 세계 리졸버에 새 값이 퍼졌는지까지 검증하면 마무리다.