DNS 레코드 유형 완벽 가이드: A 레코드부터 CAA까지 실전 구성 매뉴얼

핵심 결론: DNS 레코드는 도메인과 인터넷 서비스를 연결하는 다리입니다. A, CNAME, MX, TXT, CAA 등의 레코드 유형을 올바르게 구성하면 웹사이트 접속, 이메일 전달, SSL 인증서 발급의 정상 작동 여부가 직접 결정됩니다. 2024년부터 Google과 Yahoo는 SPF/DKIM/DMARC 이메일 인증을 의무화했으며, 미구성 도메인은 이메일 수신 거부 위험에 직면합니다.

도메인 등록을 완료한 후, 실제로 도메인이 “작동"하게 만드는 핵심 작업이 바로 DNS 레코드 구성입니다. 웹사이트 구축, 기업 이메일 설정, CDN 연동, 도메인 소유권 인증 등 모든 작업에는 다양한 DNS 레코드 유형에 대한 이해와 올바른 설정이 필수적입니다.

이 가이드에서는 10가지 핵심 DNS 레코드 유형의 구성 구문, 적용 시나리오, 일반적인 실수를 하나씩 다루며, 2024년 이메일 인증 의무 규정과 CA/B Forum 최신 SSL 인증서 정책까지 포괄하여 도메인 구성의 보안성과 효율성을 모두 확보할 수 있도록 안내합니다.

DNS 레코드 유형 빠른 비교표

각 레코드 유형을 심층적으로 살펴보기 전에, 비교표를 통해 전체 구조를 파악합니다:

A 레코드: 도메인 해석의 기초

**A 레코드(Address Record)**는 DNS 시스템에서 가장 기본적이고 널리 사용되는 레코드 유형으로, 도메인을 IPv4 주소에 직접 매핑합니다.

구성 구문

example.com.    3600    IN    A    192.0.2.1

각 필드의 의미:

• example.com. — 도메인명(마지막 점은 FQDN을 의미)
• 3600 — TTL 생존 시간(초), 캐시 유효 기간
• IN — 인터넷 클래스
• A — 레코드 유형
• 192.0.2.1 — 대상 IPv4 주소

실전 시나리오

시나리오 1: 단일 서버 지정

루트 도메인과 www 서브도메인 모두를 웹 서버로 지정하는 경우:

example.com.      300    IN    A    203.0.113.50
www.example.com.  300    IN    A    203.0.113.50

시나리오 2: 로드 밸런싱(Round-Robin DNS)

여러 A 레코드를 구성하여 간단한 부하 분산을 구현:

example.com.    300    IN    A    203.0.113.50
example.com.    300    IN    A    203.0.113.51
example.com.    300    IN    A    203.0.113.52

DNS가 라운드 로빈 방식으로 다른 IP를 반환하여 트래픽을 여러 서버에 분산합니다.

일반적인 실수

• TTL을 너무 길게 설정: 프로덕션 환경 변경 전 TTL을 60-300초로 낮추고, 마이그레이션 완료 후 3600초로 복구
• 모든 레코드 업데이트 누락: 서버 IP 변경 시 모든 서브도메인의 A 레코드를 반드시 확인
• CNAME과의 충돌: 동일 도메인에 A 레코드와 CNAME 레코드가 동시에 존재할 수 없음

AAAA 레코드: IPv6 미래를 위한 대비

AAAA 레코드는 A 레코드와 기능이 동일하며, IPv4 대신 IPv6 주소를 가리킨다는 점만 다릅니다. 전 세계 IPv4 주소가 고갈되면서 IPv6 배포가 가속화되고 있으며, Google 통계에 따르면 2025년 글로벌 IPv6 채택률은 이미 45%를 넘었습니다.

구성 구문

example.com.    3600    IN    AAAA    2001:0db8:85a3::8a2e:0370:7334

모범 사례

A 레코드와 AAAA 레코드를 동시에 구성(듀얼 스택 모드)하여 IPv4와 IPv6 네트워크 모두에서 도메인에 정상 접속되도록 설정하는 것을 권장합니다:

example.com.    3600    IN    A       203.0.113.50
example.com.    3600    IN    AAAA    2001:db8::1

CNAME 레코드: 유연한 도메인 별칭

**CNAME 레코드(Canonical Name Record)**는 하나의 도메인을 다른 도메인으로 가리켜 본질적으로 “별칭” 관계를 생성합니다.

구성 구문

www.example.com.     3600    IN    CNAME    example.com.
blog.example.com.    3600    IN    CNAME    hosting.provider.com.
shop.example.com.    3600    IN    CNAME    shops.myshopify.com.

핵심 제한 규칙

규칙 1: 루트 도메인(Apex)에 CNAME 설정 불가

아래 구성은 잘못된 것입니다:

example.com.    CNAME    other.com.    (X) RFC 1912 위반

루트 도메인은 반드시 A 레코드를 사용해야 합니다. CDN이나 클라우드 플랫폼에서 CNAME 연동을 요구하는 경우, ALIAS/ANAME 레코드(일부 DNS 제공업체에서 지원)를 대안으로 사용할 수 있습니다.

규칙 2: CNAME은 다른 레코드와 공존 불가

같은 도메인에 CNAME 레코드가 있으면 MX, TXT 등 어떤 다른 유형의 레코드도 추가할 수 없습니다.

A 레코드 vs CNAME 레코드 선택 가이드

MX 레코드: 이메일 라우팅의 핵심

**MX 레코드(Mail Exchange Record)**는 도메인으로 전송되는 이메일을 어떤 메일 서버로 전달할지 지정합니다.

구성 구문

example.com.    3600    IN    MX    10    mail1.example.com.
example.com.    3600    IN    MX    20    mail2.example.com.
example.com.    3600    IN    MX    30    mail3.backup-mx.com.

우선순위 수치가 낮을수록 우선순위가 높습니다. 위 구성에서 이메일은 먼저 mail1로 전송되고, mail1이 불가능하면 mail2를 시도하며, 마지막으로 백업 서버를 사용합니다.

주요 이메일 서비스 MX 구성

Google Workspace:

example.com.    MX    1     ASPMX.L.GOOGLE.COM.
example.com.    MX    5     ALT1.ASPMX.L.GOOGLE.COM.
example.com.    MX    5     ALT2.ASPMX.L.GOOGLE.COM.
example.com.    MX    10    ALT3.ASPMX.L.GOOGLE.COM.
example.com.    MX    10    ALT4.ASPMX.L.GOOGLE.COM.

Microsoft 365:

example.com.    MX    0    example-com.mail.protection.outlook.com.

Naver Works(네이버 웍스):

example.com.    MX    10    mx1.worksmobile.com.
example.com.    MX    20    mx2.worksmobile.com.

일반적인 문제 해결

• 이메일 수신 불가: MX 레코드가 올바른 메일 서버를 가리키는지, 우선순위 설정이 적절한지 확인
• MX가 IP를 가리킴: MX 레코드의 값은 반드시 도메인명이어야 하며 IP 주소가 아님. 해당 메일 서버 도메인을 해석하기 위한 별도의 A 레코드 필요
• CNAME 충돌: 특정 서브도메인에 CNAME이 설정되어 있으면 해당 서브도메인에 MX 레코드 구성 불가

TXT 레코드: 검증과 보안의 만능 매체

TXT 레코드는 도메인 관리자가 DNS에 임의의 텍스트 정보를 저장할 수 있게 합니다. 용도가 매우 광범위하며, 현대 도메인 보안 구성의 핵심입니다.

구성 구문

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

주요 용도

1. SPF 레코드(이메일 위조 방지)

SPF(Sender Policy Framework)는 어떤 서버가 해당 도메인 명의로 이메일을 보낼 권한이 있는지 선언합니다:

example.com.    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all"

구문 설명:

• include: — 서드파티 서비스의 발신 도메인 인가
• ip4: — IP 대역 직접 인가
• -all — 엄격 모드, 목록에 없는 서버의 메일 일체 거부(권장)
• ~all — 소프트 거부, 의심으로 표시하되 직접 거부하지 않음

중요 안내: 2024년 2월부터 Google과 Yahoo는 일일 5,000통 이상 발송하는 도메인에 SPF, DKIM, DMARC 구성을 의무화했습니다. 미준수 도메인의 이메일은 직접 거부되거나 스팸함으로 이동됩니다.

2. DKIM 레코드(이메일 서명 검증)

DKIM(DomainKeys Identified Mail)은 암호화 서명을 통해 이메일이 위변조되지 않았음을 검증합니다:

selector1._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

구성 단계:

1. 이메일 서비스 제공업체에서 키 쌍 생성
2. 공개키를 TXT 레코드 형태로 DNS에 게시
3. 발신되는 모든 이메일에 암호화 서명 자동 첨부
4. 수신 측에서 DNS 조회로 공개키를 확인하여 서명 검증

2048비트 이상의 RSA 키 사용을 권장합니다.

3. DMARC 레코드(인증 정책 및 보고)

DMARC(Domain-based Message Authentication, Reporting & Conformance)는 수신 측에 SPF/DKIM 검증 실패 이메일의 처리 방법을 알려줍니다:

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"

단계적 배포 전략 권장:

4. 도메인 소유권 인증

Google Search Console, 각종 클라우드 플랫폼, SaaS 서비스에서 도메인 소유권 인증을 위해 TXT 레코드 추가를 요구하는 경우가 많습니다:

example.com.    TXT    "google-site-verification=abcdefg12345"
example.com.    TXT    "v=verify; service=example-saas; id=123456"

NS 레코드: 권한 DNS 위임

**NS 레코드(Name Server Record)**는 해당 도메인에 대해 권한 해석을 담당하는 DNS 서버를 지정합니다.

구성 구문

example.com.    86400    IN    NS    ns1.cloudflare.com.
example.com.    86400    IN    NS    ns2.cloudflare.com.

NS 레코드를 수정해야 하는 경우

• DNS 서비스 제공업체 변경: 등록기관 기본 DNS에서 Cloudflare, AWS Route 53 등 전문 DNS로 이전
• 서브도메인 위임: 특정 서브도메인의 해석 권한을 다른 DNS 서버에 위임

api.example.com.    NS    ns1.api-dns-provider.com.
api.example.com.    NS    ns2.api-dns-provider.com.

SOA 레코드: 존 파일의 메타데이터

**SOA 레코드(Start of Authority)**는 DNS 존의 관리 정보를 저장하며, 각 존에 하나의 SOA 레코드만 존재합니다.

구성 구문

example.com.    SOA    ns1.example.com. admin.example.com. (
    2026052201    ; 시리얼 번호(YYYYMMDDnn 형식 권장)
    7200          ; 갱신 간격(초)
    3600          ; 재시도 간격
    1209600       ; 만료 시간
    86400         ; 네거티브 캐시 TTL
)

일반 사용자는 SOA 레코드를 직접 수정할 필요가 거의 없으며, DNS 서비스 제공업체가 자동으로 관리합니다. 그러나 시리얼 번호 메커니즘을 이해하면 DNS 동기화 문제를 해결하는 데 도움이 됩니다. 존 파일을 수정할 때마다 시리얼 번호가 반드시 증가해야 세컨더리 서버가 업데이트를 동기화합니다.

PTR 레코드: 역방향 DNS 조회

**PTR 레코드(Pointer Record)**는 IP에서 도메인으로의 역방향 조회를 구현하며, A/AAAA 레코드의 “거울 이미지"입니다.

구성 구문

IPv4 역방향 조회는 IP 주소를 역순으로 배열하고 .in-addr.arpa 접미사를 추가합니다:

50.113.0.203.in-addr.arpa.    PTR    mail.example.com.

PTR 레코드가 중요한 이유

이메일 전달이 PTR 레코드의 가장 중요한 적용 시나리오입니다. 주요 메일 서비스 제공업체(Gmail, Outlook, Naver 메일)는 발신 IP의 PTR 레코드가 발신 도메인과 일치하는지 확인합니다(FCrDNS 검증). PTR 레코드가 불일치하거나 누락된 메일 서버의 이메일은 수신 거부되거나 스팸으로 분류될 가능성이 높습니다.

PTR 레코드를 구성하려면 IP 주소 할당자(일반적으로 VPS/클라우드 서버 제공업체)에 연락하여 해당 제어판에서 역방향 DNS를 설정해야 합니다.

SRV 레코드: 서비스 검색 프로토콜

**SRV 레코드(Service Record)**는 특정 서비스를 제공하는 호스트와 포트를 지정하며, VoIP, 메신저, 게임 서버 등의 시나리오에서 자주 사용됩니다.

구성 구문

_service._protocol.example.com.    SRV    priority weight port target

실제 예시:

_sip._tcp.example.com.       SRV    10 60 5060 sip1.example.com.
_xmpp._tcp.example.com.      SRV    5  0  5222 xmpp.example.com.
_minecraft._tcp.example.com.  SRV    0  5  25565 mc.example.com.

일반적인 활용

• Microsoft Teams/Skype for Business: SRV 레코드를 통해 통신 서버 검색
• SIP 전화 시스템: VoIP 장치가 SIP 서버를 자동 탐색
• XMPP/Jabber: 메신저 클라이언트가 채팅 서버 검색
• 게임 서버: Minecraft 등 게임에서 SRV 레코드로 사용자 정의 포트 연결

CAA 레코드: SSL 인증서 발급 제어

**CAA 레코드(Certificate Authority Authorization)**는 도메인에 대해 SSL/TLS 인증서를 발급할 수 있는 인증 기관(CA)을 지정합니다. 인증서 오발급을 방지하는 중요한 보안 수단입니다.

구성 구문

example.com.    CAA    0 issue "letsencrypt.org"
example.com.    CAA    0 issuewild "letsencrypt.org"
example.com.    CAA    0 iodef "mailto:security@example.com"

태그 설명:

• issue — 일반 인증서 발급을 인가하는 CA
• issuewild — 와일드카드 인증서 발급을 인가하는 CA
• iodef — 규칙 위반 발급 시 알림 이메일

지금 CAA 레코드를 반드시 구성해야 하는 이유

CA/B Forum은 2025년 4월 Ballot SC-081v3를 통과시켰으며, SSL 인증서 유효 기간이 단계적으로 단축됩니다:

인증서 갱신 빈도가 대폭 증가한다는 것은 자동화 발급 프로세스가 일상이 된다는 의미입니다. CAA 레코드를 구성하면 인가된 CA만 인증서를 자동 발급할 수 있도록 보장하여, 자동화 프로세스에서의 보안 취약점을 방지할 수 있습니다.

권장 구성 방안

Let’s Encrypt 무료 인증서를 사용하는 경우:

example.com.    CAA    0 issue "letsencrypt.org"
example.com.    CAA    0 issuewild "letsencrypt.org"
example.com.    CAA    0 iodef "mailto:admin@example.com"

여러 CA를 동시에 사용하는 경우:

example.com.    CAA    0 issue "letsencrypt.org"
example.com.    CAA    0 issue "digicert.com"
example.com.    CAA    0 issue "sectigo.com"

DNS 레코드 구성 의사결정 트리

구체적인 요구 상황에서 올바른 레코드 유형을 선택하는 방법은 다음 의사결정 흐름을 참고하세요:

웹사이트 접근이 필요한 경우

• 루트 도메인 → A 레코드 추가(서버 IP 지정)
• www 또는 기타 서브도메인 → CNAME(루트 도메인 또는 CDN 지정)
• IPv6 접근 필요 → AAAA 레코드도 함께 추가

이메일 구성이 필요한 경우

• 이메일 라우팅 → MX 레코드
• 발신 인증 → TXT 레코드(SPF + DKIM + DMARC)
• 메일 서버 역방향 검증 → PTR 레코드

도메인 소유권 인증이 필요한 경우

• Google/Microsoft 등 플랫폼 인증 → TXT 레코드

보안 보장이 필요한 경우

• SSL 인증서 발급 CA 제한 → CAA 레코드
• DNS 데이터 무결성 → DNSSEC

특정 서비스 연동이 필요한 경우

• VoIP/메신저/게임 → SRV 레코드
• CDN/SaaS 플랫폼 → CNAME 레코드

DNS 레코드 구성 실전: 처음부터 완전한 도메인 설정

Nameslink에서 도메인을 구매했다고 가정하고, 완전한 DNS 구성 절차를 살펴보겠습니다:

1단계: 기본 웹사이트 해석

example.com.       300    IN    A       203.0.113.50
example.com.       300    IN    AAAA    2001:db8::50
www.example.com.   300    IN    CNAME   example.com.

2단계: 이메일 시스템 구성

; MX 레코드
example.com.    MX    10    mail.example.com.
mail.example.com.    A    203.0.113.25

; SPF
example.com.    TXT    "v=spf1 ip4:203.0.113.25 include:_spf.google.com -all"

; DKIM
selector._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=공개키내용"

; DMARC
_dmarc.example.com.    TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

3단계: 보안 강화

; CAA로 인증서 발급 제한
example.com.    CAA    0 issue "letsencrypt.org"
example.com.    CAA    0 iodef "mailto:admin@example.com"

4단계: TTL 전략

• 안정 운영 기간: TTL을 3600초(1시간)로 설정
• 변경 계획 전: 미리 TTL을 60-300초로 낮춤
• 변경 완료 후: 이상 없음을 확인한 후 3600초로 복구

DNS 레코드 문제 해결 도구와 방법

DNS 구성이 적용되지 않거나 이상이 발생할 때 다음 도구를 사용하여 문제를 파악합니다:

커맨드라인 도구

dig 명령어(권장):

# A 레코드 조회
dig example.com A

# 특정 DNS 서버에 조회
dig @8.8.8.8 example.com MX

# 전체 해석 경로 추적
dig +trace example.com

# TXT 레코드 조회
dig example.com TXT

# CAA 레코드 조회
dig example.com CAA

nslookup 명령어:

nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8

host 명령어(간단한 조회):

host -t MX example.com
host -t TXT example.com

온라인 검사 도구

도메인의 해석 상태와 사용 가능한 확장자를 빠르게 확인하려면 Nameslink 도메인 검사 도구를 활용할 수 있습니다. 1,500개 이상의 확장자를 밀리초 단위로 검사할 수 있어, DNS 구성 전 도메인 상태를 확인하는 데 편리합니다.

일반적인 문제 진단

TTL 설정 모범 사례

TTL(Time To Live)은 DNS 레코드가 캐시되는 시간을 결정하며, DNS 변경의 적용 속도에 직접 영향을 줍니다.

핵심 원칙: 계획된 DNS 변경 전에는 최소 현재 TTL 주기 이전에 레코드의 TTL을 미리 낮춰야 합니다. 예를 들어 현재 TTL이 86400초(24시간)라면, 최소 24시간 전에 TTL을 300초로 변경한 후 IP 변경 작업을 실행합니다.

자주 묻는 질문(FAQ)

DNS 레코드 수정 후 적용까지 얼마나 걸리나요?

DNS 레코드의 적용 시간은 이전 레코드의 TTL 값에 따라 결정됩니다. 이전 레코드의 TTL이 3600초였다면 전 세계 범위에서 최대 1시간까지 기다려야 합니다. 실제로는 각 단계의 DNS 캐시가 존재하므로 완전한 글로벌 적용에는 24-48시간이 소요될 수 있습니다. 변경 계획 전에 미리 TTL을 낮추는 것을 권장합니다.

A 레코드와 CNAME 레코드 중 어떤 것을 선택해야 하나요?

루트 도메인은 A 레코드만 사용할 수 있고, 서브도메인은 CNAME을 우선 사용합니다. CNAME의 장점은 대상 주소가 변경될 때 서브도메인 레코드를 일일이 업데이트할 필요가 없다는 것입니다. 단, 같은 도메인에 MX나 TXT 레코드를 구성해야 하는 경우 해당 도메인에는 CNAME을 사용할 수 없습니다.

SPF 레코드가 DNS 조회 10회 제한을 초과하면 어떻게 하나요?

SPF 표준은 최대 10회의 DNS lookup(include/a/mx 등 메커니즘마다 1회씩 계산)을 제한합니다. 해결 방안으로는 여러 include를 ip4/ip6 직접 인가로 통합하거나, SPF Flattening 도구를 사용하여 중첩된 도메인을 IP 목록으로 해석하거나, 서로 다른 발송 서비스를 별도의 서브도메인에 배정하는 방법이 있습니다.

MX 레코드를 구성했는데 이메일이 수신되지 않는 이유는 무엇인가요?

MX 레코드의 값은 반드시 도메인명이어야 하며 IP 주소가 아니고, 해당 도메인에 대응하는 A 레코드가 있어야 합니다. 또한 MX 우선순위 설정이 올바른지(수치가 작을수록 우선순위 높음), 방화벽에서 25/587/993 등 이메일 포트가 개방되어 있는지도 확인하세요.

CAA 레코드는 반드시 구성해야 하나요?

CAA 레코드는 강제 사항은 아니지만, 구성을 강력히 권장합니다. 2017년부터 CA는 인증서 발급 전 CAA 레코드를 반드시 확인해야 합니다. 특히 CA/B Forum이 SSL 인증서 유효 기간을 47일까지 단축하는 신규 정책을 통과시킨 이후, 자동화 인증서 갱신이 일상화될 것이며, CAA 레코드는 비인가 CA의 잘못된 인증서 발급을 효과적으로 방지합니다. CAA 레코드를 구성하지 않으면 모든 CA가 해당 도메인에 대해 인증서를 발급할 수 있습니다.

요약 및 실행 체크리스트

DNS 레코드 구성은 복잡해 보이지만, 핵심 논리를 파악하면 대부분의 시나리오에 대응할 수 있습니다. 다음은 가장 중요한 실행 요점입니다:

즉시 확인: 도메인에 SPF, DKIM, DMARC가 구성되어 있나요? 2024년 2월부터 Google과 Yahoo는 이메일 인증 미구성 도메인에 엄격한 필터링을 적용하고 있습니다. dig yourdomain.com TXT와 dig _dmarc.yourdomain.com TXT로 현재 상태를 확인하세요.

단기 계획: CAA 레코드를 추가하여 SSL 인증서 발급 CA를 제한하세요. 인증서 유효 기간이 단계적으로 47일까지 단축됨에 따라, 자동화 발급의 보안 보호가 더욱 중요해집니다.

지속적 유지보수: 정기적으로 DNS 레코드를 감사하고, 더 이상 사용하지 않는 해석 항목을 삭제하여 DNS 존 파일을 깔끔하게 유지하세요. 분기별 점검을 통해 모든 레코드가 올바른 대상을 가리키고 있는지 확인하는 것을 권장합니다.

새 도메인 등록을 계획 중이라면, 구매 전에 Nameslink 도메인 가치 평가 도구를 통해 도메인의 종합 가치(SEO 가중치, 브랜드성, 길이 등 22개 지표 포함)를 평가해보는 것을 추천합니다. 이는 이후 DNS 구성 전략 수립에도 참고가 됩니다.

데이터 출처 및 참고:

• RFC 1035 — Domain Names: Implementation and Specification (IETF, 1987)
• RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email (IETF, 2014)
• RFC 6844 — DNS Certification Authority Authorization (CAA) Resource Record (IETF, 2013)
• CA/Browser Forum Ballot SC-081v3 — Reducing Validity Period of Subscriber Certificates (2025년 4월)
• Google Email Sender Guidelines — Bulk Sender Requirements (2024년 2월 시행)
• Internet Society Global IPv6 Deployment Report (2025)