DNS 레코드 유형: 개요

모든 DNS 레코드는 질문에 답합니다. "IP 주소가 뭐야?"라는 단순한 질문뿐 아니라 "메일을 어디로 보내야 해?", "이 도메인에 누가 인증서를 발급할 수 있어?", "이 응답을 신뢰할 수 있어?" 같은 질문들에도 답합니다.

레코드 유형은 묻는 질문입니다. 레코드 데이터는 그 답입니다.

DNS의 문법

리소스 레코드는 이름, 유형, 클래스, TTL, 데이터라는 단순한 구조를 따릅니다. 하지만 의미가 살아있는 곳은 유형 필드입니다. 유형은 원시 데이터를 명령으로 바꿉니다.

192.0.2.1이라는 데이터는 그 자체로는 아무 의미가 없습니다. A 레코드에 넣으면 명령이 됩니다: 여기로 접속하라. 유형이 동사입니다.

주소 레코드: A와 AAAA

A 레코드는 가장 근본적인 질문에 답합니다: "어떤 IPv4 주소로 접속해야 해?"

example.com.    A    192.0.2.1

브라우저가 example.com에 접속해야 할 때 A 레코드를 요청하고 접속할 주소를 받습니다. 모든 것의 토대가 바로 이것입니다.

AAAA 레코드는 IPv6에 대해 같은 질문에 답합니다:

example.com.    AAAA    2001:db8:85a3::8a2e:370:7334

이름이 임의적이지 않습니다—IPv6 주소는 IPv4보다 네 배 길기 때문에 A가 네 개입니다. 현대 사이트라면 둘 다 갖춰야 합니다. 인터넷도 이제는 두 가지 언어를 쓰는 시대가 됐습니다.

CNAME 레코드: 리다이렉트

CNAME은 장소를 가리키지 않습니다—다른 질문을 가리킵니다.

www.example.com.    CNAME    example.com.

"www.example.com은 어디에 있어?" "example.com에 물어봐."

리졸버는 경로를 따라가며 example.com의 A 레코드를 찾아 실제 주소를 얻습니다. 이 간접성은 CDN과 클라우드 서비스에서 큰 힘을 발휘합니다—여러분이 DNS를 건드리지 않아도 그쪽에서 IP 주소를 바꿀 수 있으니까요.

하지만 CNAME에는 제약이 있습니다: 최상위 도메인(베어 도메인)에는 사용할 수 없습니다. CNAME은 "이 이름이 바로 저 이름이다"를 의미합니다—완전한 별칭입니다. 최상위 도메인에는 이미 별칭을 만들 수 없는 NS와 SOA 레코드가 있습니다. 거기에 CNAME을 놓으면 논리적 모순이 생깁니다: 이름이 다른 무언가이면서 동시에 자체적인 권한 레코드를 가질 수는 없습니다.

MX 레코드: 메일 라우팅

MX 레코드는 "이 도메인의 메일을 어디로 배달해야 해?"에 답합니다:

example.com.    MX    10 mail1.example.com.
example.com.    MX    20 mail2.example.com.

숫자는 우선순위입니다—낮을수록 "먼저 시도"를 의미합니다. mail1이 다운되면 발신자는 mail2를 시도합니다. 프로토콜 자체에 내장된 이중화입니다.

MX 레코드는 IP 주소가 아니라 호스트명을 가리킵니다. 메일 서버의 호스트명에는 자체 A 레코드가 필요합니다. 이 간접성 덕분에 다른 모든 사람의 DNS를 업데이트하지 않고도 메일 서버를 이전할 수 있습니다.

TXT 레코드: 만능 창구

TXT 레코드는 텍스트를 담습니다. 이 단순함이 무한한 유연성을 만듭니다:

SPF는 메일을 보낼 수 있는 서버를 선언합니다:

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

DKIM은 이메일 서명 검증을 위한 공개 키를 제공합니다:

selector._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIGf..."

도메인 소유 확인은 도메인에 대한 제어권을 증명합니다:

example.com.    TXT    "google-site-verification=abc123..."

TXT 레코드는 DNS가 원래 다루도록 설계되지 않은 모든 것의 만능 창구가 되었습니다. 서비스를 위해 임의 데이터를 저장해야 하나요? TXT 레코드를 쓰면 됩니다.

NS 레코드: 위임

NS 레코드는 "이 영역에 권한을 가진 곳은 어디야?"에 답합니다:

example.com.    NS    ns1.provider.com.
example.com.    NS    ns2.provider.com.

이는 도메인에 관한 질문에 답할 수 있는 네임 서버를 가리킵니다. 모든 도메인은 이중화를 위해 최소 두 개가 필요합니다.

NS 레코드는 하위 도메인 위임도 가능하게 합니다. api.example.com을 다른 DNS 제공업체가 관리하기를 원하나요? 해당 하위 도메인에 그쪽 서버를 가리키는 NS 레코드를 추가하면 됩니다. 권한이 깔끔하게 이전됩니다.

PTR 레코드: 역방향 조회

대부분의 DNS 쿼리는 "이 이름의 주소가 뭐야?"라고 묻습니다. PTR 레코드는 반대로 답합니다: "이 주소에 속하는 이름은 뭐야?"

이것은 신뢰와 직결됩니다. 메일 서버가 mail.example.com이라고 주장하며 연결할 때, 받는 서버는 확인할 수 있습니다: "당신이 mail.example.com이라고 하는데. 당신의 IP 주소도 그것을 뒷받침합니까?" PTR 레코드가 다른 곳을 가리킨다면, 그것은 수상쩍은 일입니다.

PTR 레코드는 특별한 역방향 영역(1.2.0.192.in-addr.arpa 같은 곳)에 존재하며, IP 주소를 소유한 사람—보통 여러분이 아닌 호스팅 제공업체—이 관리합니다.

SOA 레코드: 영역 메타데이터

모든 DNS 영역에는 정확히 하나의 SOA(Start of Authority) 레코드가 있습니다. 기본 네임 서버, 연락처 이메일, 시리얼 번호, 그리고 보조 서버가 동기화하는 방식을 제어하는 타이밍 값 등 관리 메타데이터입니다.

SOA 레코드를 직접 편집하는 경우는 드뭅니다. 하지만 DNS 변경 사항이 전파되지 않을 때 시리얼 번호가 종종 원인입니다—보조 서버가 업데이트를 인식하려면 시리얼 번호가 반드시 증가해야 합니다.

특수 레코드

SRV: 서비스 검색

SRV 레코드는 "이 특정 서비스를 위한 서버가 어디에 있어?"에 답합니다:

_sip._tcp.example.com.    SRV    10 5 5060 sipserver.example.com.

TCP를 통한 SIP의 경우, 포트 5060의 sipserver.example.com에 접속합니다. 숫자는 우선순위와 부하 분산을 처리합니다. SRV 레코드는 서비스가 어디에 있는지뿐만 아니라 어떻게 접속하는지도 알려줍니다.

CAA: 인증서 제어

CAA 레코드는 "어떤 인증 기관이 이 도메인의 인증서를 발급할 수 있어?"에 답합니다:

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

인증서를 발급하기 전에 CA는 CAA 레코드를 확인해야 합니다. Let's Encrypt만 도메인에 발급할 수 있다고 선언하면 다른 CA는 거부합니다. 이는 무단 인증서 발급을 방지합니다—실제로 악용된 공격 경로입니다.

DNSKEY: 암호화 신뢰

DNSSEC는 DNS 응답에 서명을 추가하며, DNSKEY 레코드는 검증을 위한 공개 키를 담습니다. 이는 공격자가 응답을 위조하는 것을 방지합니다.

대부분의 도메인 소유자는 DNSKEY 레코드를 직접 건드리지 않습니다—DNS 제공업체가 암호화를 처리합니다. 하지만 이것이 존재한다는 것을 알면 DNS가 스푸핑으로부터 어떻게 보호될 수 있는지 이해하는 데 도움이 됩니다.

레코드 선택

DNS 레코드 유형에 관한 자주 묻는 질문

루트 도메인에 CNAME을 놓을 수 없는 이유는?

CNAME은 "이 이름이 바로 저 이름이다"를 의미합니다—완전한 별칭입니다. 하지만 루트 도메인에는 이미 NS 레코드(네임 서버를 가리키는)와 SOA 레코드(영역 메타데이터)가 있습니다. DNS 규칙은 다른 레코드가 CNAME과 공존하는 것을 금지합니다. 루트 도메인이 CNAME이 되려면 NS 레코드를 포기해야 하는데, 그러면 DNS 해석이 완전히 망가집니다. 일부 제공업체는 ALIAS나 ANAME 레코드 같은 우회 방법을 제공하는데, 이는 쿼리 시점에 CNAME을 해석하여 결과 주소를 직접 반환합니다.

MX 우선순위 10과 20의 차이는?

낮은 숫자가 더 높은 우선순위를 의미합니다. 메일 서버는 우선순위 10을 먼저 시도합니다. 해당 서버에 접근할 수 없으면 우선순위 20으로 넘어갑니다. 이것은 부하 분산이 아니라 장애 조치입니다. 서버 간에 트래픽을 분산하려면 같은 우선순위 번호를 부여하면 됩니다.

A 레코드와 AAAA 레코드 모두 필요한가요?

A 레코드는 IPv4 사용자가 접속할 수 있게 합니다. AAAA 레코드는 IPv6 사용자가 직접 연결할 수 있게 합니다. 대부분의 호스팅 제공업체는 이제 두 주소를 모두 제공합니다. 둘 다 사용하는 것이 좋은 관행입니다—IPv6 도입이 계속 늘어나고 있으며, 일부 모바일 및 기업 네트워크는 IPv6 전용입니다.

DNS 변경 사항이 전파되는 데 얼마나 걸리나요?

TTL(생존 시간)에 달려 있습니다. 레코드의 TTL이 3600초라면 리졸버는 한 시간 동안 캐시할 수 있습니다. 변경 후에는 캐시된 복사본이 만료될 때까지 기다려야 합니다. 미리 계획하고 있나요? 변경하기 전에 TTL을 낮추고, 이전 TTL이 지날 때까지 기다린 다음 변경하세요. 전파가 훨씬 빨라질 것입니다.

TXT 레코드 주위에 왜 따옴표가 있나요?

TXT 레코드 데이터는 문자 문자열의 시퀀스로 저장됩니다. 따옴표는 영역 파일 형식에서 각 문자열의 경계를 표시합니다. 255자를 초과하는 레코드(DKIM 키에서 흔함)는 리졸버가 이어 붙이는 여러 개의 따옴표 문자열로 분할됩니다. 대부분의 DNS 인터페이스는 이를 자동으로 처리합니다—그냥 긴 문자열을 붙여넣으면 됩니다.