2025년 11월 21일·7분
Paul Mockapetris와 DNS: 인터넷에 사람 친화적 이름이 생긴 방법
Paul Mockapetris가 HOSTS.TXT의 취약함을 해결하고 확장 가능한 도메인 네임 시스템(DNS)을 설계한 과정을 배우세요. DNS의 동작 원리, 캐싱의 중요성, 기본 보안 개념을 알기 쉽게 설명합니다.
Paul Mockapetris가 HOSTS.TXT의 취약함을 해결하고 확장 가능한 도메인 네임 시스템(DNS)을 설계한 과정을 배우세요. DNS의 동작 원리, 캐싱의 중요성, 기본 보안 개념을 알기 쉽게 설명합니다.
웹 주소를 입력하거나 링크를 클릭하고 이메일을 보낼 때마다, 당신은 간단한 아이디어에 의존하고 있습니다: 사람이 기억하기 쉬운 이름을 쓰고, 컴퓨터가 적절한 기계를 찾아주는 것.
DNS는 일상적인 문제를 해결합니다: 컴퓨터는 203.0.113.42 같은 숫자 주소(IP 주소)를 사용해 통신하지만, 사람은 숫자 문자열을 외우고 싶어하지 않습니다. 당신은 오늘 그 사이트가 쓰는 주소가 무엇인지가 아니라 example.com을 기억하고 싶습니다.
도메인 네임 시스템(DNS)은 사람이 읽기 쉬운 도메인 이름을 컴퓨터가 연결하는 데 쓰는 IP 주소로 번역하는 인터넷의 "주소록"입니다.
이 번역은 사소해 보일 수 있지만, 인터넷이 사용하기 편한 것인지 아니면 완전히 숫자로만 된 전화번호부처럼 느껴지는지의 차이를 만듭니다.
이 글은 비기술자용 안내입니다—네트워킹 배경 지식이 필요하지 않습니다. 다룰 내용은:\n
중간중간 당신은 1980년대 초 DNS를 설계한 엔지니어 Paul Mockapetris를 만나게 됩니다. 그의 작업은 단순히 새 이름 형식을 만든 것이 아니라 — 인터넷이 작은 연구망에서 수십억 명이 쓰는 시스템으로 확장될 때까지 견딜 수 있는 시스템을 설계했다는 점에서 중요합니다.
사이트가 “다운”되었거나 도메인 변경이 “전파”되기를 기다려본 적이 있거나, 이메일 설정에 이상한 DNS 항목이 왜 필요한지 궁금했다면, 외부에서 이미 DNS를 만난 셈입니다. 이 글은 배경에서 무슨 일이 일어나는지 명확하고 전문 용어를 최소화해 설명합니다.
누군가 친숙한 웹 주소를 타이핑하기 훨씬 이전, 초기 네트워크는 더 단순한 문제를 안고 있었습니다: 특정 기계에 어떻게 도달하나? 컴퓨터는 IP 주소(예: 10.0.0.5)로 통신할 수 있었지만, 사람은 MIT-MC나 SRI-NIC 같은 호스트명을 더 쉽게 기억하고 공유했습니다.
초기 ARPANET에서는 해결책이 HOSTS.TXT라는 하나의 공유 파일이었습니다. 본질적으로 조회표였고, 호스트명과 IP 주소가 쌍으로 적혀 있었습니다.
각 컴퓨터는 이 파일의 로컬 복사본을 보관했습니다. 이름으로 기계에 연결하려면 시스템이 HOSTS.TXT를 확인해 해당 IP 주소를 찾았습니다.
네트워크가 작고 변화가 적었으며 업데이트를 받을 수 있는 명확한 장소가 있었기 때문에 처음에는 잘 작동했습니다.
조직이 늘어나면서 이 접근법은 정상적인 성장만으로도 금세 무너지기 시작했습니다:\n
핵심 문제는 조정(coordination)이었습니다. HOSTS.TXT는 전 세계를 위한 하나의 주소록과 같았습니다. 모든 사람이 같은 책에 의존하면, 모든 수정은 전역 편집을 필요로 하고, 모든 사람은 최신 버전을 빨리 받아야 합니다. 네트워크가 일정 규모에 도달하면 ‘모든 것을 위한 하나의 파일’ 모델은 너무 느리고 중앙집중적이며 오류에 약해졌습니다.
DNS는 이름을 숫자로 매핑하는 개념을 없애지 않았습니다—대신 그 매핑을 유지하고 배포하던 취약한 방식을 대체했습니다.
1980년대 초, 인터넷은 작은 연구망에서 더 크고 혼잡하며 널리 공유되는 네트워크로 변하고 있었습니다. 더 많은 기계가 합류하고 조직들은 자율성을 원했으며 사람들은 숫자 주소를 외우는 것보다 더 쉬운 방법으로 서비스에 접근하길 원했습니다.
그 환경에서 일하던 Paul Mockapetris는 DNS 설계자로 널리 인정받고 있습니다. 그의 기여는 화려한 제품이 아니라 매우 실용적인 질문에 대한 엔지니어링 답이었습니다: 네트워크가 계속 성장할 때 이름을 어떻게 사용 가능하게 유지할 것인가?
이름 시스템은 단순해 보입니다. 하지만 그 당시의 “단순함”을 떠올려 보세요: 모든 사람이 다운로드하고 최신 상태로 유지해야 하는 하나의 공유 목록. 변화가 일상화되면 그 접근법은 깨집니다. 새 호스트, 이름 변경, 수정 하나하나가 모든 사람을 위한 조정 작업이 됩니다.
Mockapetris의 핵심 통찰은 이름이 단순한 데이터가 아니라 ‘공유 합의’라는 점이었습니다. 네트워크가 확장되면 그 합의를 만들고 배포하는 시스템도 확장되어야 하고, 모든 컴퓨터가 지속적으로 마스터 목록을 가져오게 해서는 안 된다는 것입니다.
DNS는 ‘하나의 권한 있는 파일’이라는 개념을 분산 설계로 대체했습니다:\n
이것이 조용한 탁월함입니다: DNS는 ‘영리하게’ 설계된 것이 아니라, 실제 제약—제한된 대역폭, 빈번한 변경, 많은 독립적 관리자, 끝없이 성장하는 네트워크—하에서도 작동하도록 설계되었습니다.
DNS는 교묘한 숏컷으로 발명된 것이 아니라, 초기 인터넷이 성장하면서 드러난 구체적이고 매우 실용적인 문제들을 해결하도록 설계되었습니다. Mockapetris의 접근법은 먼저 명확한 목표를 세우고, 그 다음 수십 년을 버텨낼 수 있는 이름 시스템을 구축하는 것이었습니다.
핵심 개념은 위임입니다: 서로 다른 그룹이 이름 트리의 서로 다른 부분을 관리합니다.
예를 들어, 어떤 조직은 .com 아래를 관리하고, 등록업체(레지스트라)는 당신이 example.com을 등록할 수 있도록 도와주며, 그 다음 당신(또는 당신의 DNS 제공자)이 www.example.com, mail.example.com 등의 레코드를 제어합니다. 이렇게 책임을 깔끔하게 분할하면 성장이 병목을 만들지 않습니다.
DNS는 문제가 발생할 것을 가정합니다—서버가 다운되고 네트워크가 분할되며 경로가 바뀝니다. 그래서 도메인에 여러 권한 있는 서버를 두고, 리졸버에서 캐싱을 사용해 일시적 장애가 모든 조회를 즉시 망가뜨리지 않도록 합니다.
DNS는 ‘사람 친화적 이름을 기술적 데이터(가장 흔히 IP 주소)로 번역하는 서비스’입니다. DNS는 ‘인터넷 자체’가 아니라, 당신의 기기가 어디에 연결해야 할지 찾게 도와주는 이름 및 조회 서비스입니다.
DNS는 이름을 트리처럼 조직화해서 관리 가능하게 만듭니다. 모든 이름이 전역적으로 유일해야 하고 누군가가 이를 감시해야 하는 하나의 거대한 목록 대신, DNS는 이름을 수준별로 나누고 책임을 위임합니다.
DNS 이름은 오른쪽에서 왼쪽으로 읽습니다:\n
www.example.com.은 기술적으로 .로 끝납니다.\n.com, .org, .net, 국가 코드 예: .uk\nexample(예: example.com에서)\nwww(예: www.example.com)예를 들어 www.example.com은\n
com(TLD)\nexample(TLD 아래 등록된 도메인)\nwww(도메인 소유자가 생성하고 제어하는 라벨)\n이 구조는 부모 범위 내에서만 이름이 유일하면 되기 때문에 충돌을 줄입니다. 여러 조직이 www라는 서브도메인을 가질 수 있는 이유는 www.example.com과 www.another-example.com이 서로 충돌하지 않기 때문입니다.
또한 작업량이 분산됩니다. .com 운영자는 모든 웹사이트의 레코드를 관리할 필요가 없고, example.com을 누가 책임지는지만 가리키면 도메인 소유자가 세부사항을 관리합니다.
**존(zone)**은 단순히 관리 가능한 트리의 한 조각입니다—누군가가 게시할 책임을 지는 DNS 데이터입니다. 많은 팀에게 “우리 존”은 “example.com 및 우리가 호스팅하는 서브도메인들의 DNS 레코드”를 의미하며, 이는 그들의 권한 있는 DNS 제공자에 저장됩니다.
브라우저에 웹사이트 이름을 입력하면 당신은 “인터넷 전체”에 직접 묻는 것이 아닙니다. 몇몇 전문화된 도우미가 일을 나눠서 답을 빠르고 신뢰성 있게 찾게 합니다.
**당신(기기와 브라우저)**은 단순한 요청을 시작합니다: “example.com에 해당하는 IP 주소가 무엇인가?” 기기는 보통 답을 모른 채, 여러 서버에 직접 묻고 싶어하지 않습니다.
**재귀적 리졸버(recursive resolver)**가 당신을 대신해 검색을 합니다. 이는 일반적으로 ISP, 회사/학교 IT, 또는 공개 리졸버에서 제공됩니다. 핵심 이점은 이전 조회에서 가져온 캐시된 답을 재사용할 수 있어 모두에게 속도를 빠르게 해준다는 점입니다.
권한 있는(authoritative) DNS 서버는 도메인에 대한 진실의 출처입니다. 이 서버들은 인터넷을 “검색”하지 않습니다; 그들은 도메인에 속한 어떤 IP, 메일 서버, 검증 토큰이 있는지를 담은 공식 레코드를 보유합니다.
example.com을 묻습니다.\n재귀적 리졸버는 도서관 사서처럼 당신을 대신해 찾아서 기억해 주는 존재이고, 권한 있는 서버는 출판사의 공식 카탈로그처럼 자기 책(자기 구역)에 대해 사실만을 말하는 존재입니다.
브라우저에 example.com을 입력하면, 브라우저는 실제로 이름을 찾는 것이 아니라 연결할 IP 주소(예: 93.184.216.34)를 필요로 합니다. DNS는 “이 이름의 숫자를 찾아줘”하는 시스템입니다.
브라우저는 먼저 컴퓨터/휴대폰의 운영체제에 묻습니다: “example.com의 IP를 이미 알고 있나?” OS는 자체 단기 메모리(캐시)를 확인합니다. 신선한 답이 있으면 조회는 여기서 끝납니다.
OS에 답이 없으면 DNS 리졸버—보통 ISP, 회사, 또는 공개 제공자—에 질문을 전달합니다. 리졸버는 ‘DNS 컨시어지’처럼 일을 처리해 기기가 여러 서버에 직접 묻지 않도록 해줍니다.
리졸버에 답이 캐시되어 있지 않으면 안내에 따라 검색을 시작합니다:\n
.com)에 대한 정보를 어디서 찾을지 묻습니다. 루트 서버는 최종 IP를 주지 않고 참조(referral)—“다음으로 이 .com 서버들에게 물어보라”는 방향—를 제공합니다.\n.com): 리졸버는 .com 서버들에게 example.com이 어디서 처리되는지 묻습니다. 다시 최종 IP는 아니고 “이 도메인의 권한 있는 서버에 물어보라”는 방향을 줍니다.\nA나 AAAA 같은 실제 레코드(예: IP 주소)를 반환합니다.리졸버는 IP를 OS에 보내고, 그 다음 브라우저가 연결을 시도합니다. 많은 조회가 순간적으로 느껴지는 이유는 리졸버와 기기가 TTL로 정해진 기간 동안 답을 캐시하기 때문입니다.
요약하면: 브라우저 → OS 캐시 → 리졸버 캐시 → 루트(참조) → TLD(참조) → 권한 있는(정답) → 브라우저로 반환.
모든 방문이 처음부터 여러 서버에 물어보는 과정이라면 DNS는 매우 느리게 느껴질 것입니다. 대신 DNS는 캐싱—최근 조회의 임시 ‘기억’—에 의존해 대부분의 사용자가 밀리초 단위로 답을 받게 합니다.
기기가 example.com을 리졸버에 물으면, 리졸버는 처음에는 약간의 작업을 해야 할 수 있습니다. 답을 알게 되면 캐시에 저장합니다. 다음에 같은 이름을 묻는 사람은 즉시 응답을 받을 수 있습니다.
캐싱이 있는 이유는 두 가지입니다:\n
모든 DNS 레코드는 TTL(수명) 값을 함께 제공합니다. TTL은 ‘이 답을 X초 동안 유지하고 그 후에 다시 물어봐라’는 지침입니다.
레코드의 TTL이 300이면, 리졸버는 최대 5분 동안 그 답을 재사용할 수 있습니다.
TTL은 균형의 문제입니다:\n
웹사이트를 새 호스트로 옮기거나 CDN을 전환하거나 이메일을 전환할 때(MX 레코드 변경) TTL이 사용자가 언제부터 새 장소로 가는지를 결정합니다.
일반적인 방법은 계획된 변경 전에 TTL을 낮추고 전환 후 다시 TTL을 높이는 것입니다. 그래서 평상시에는 DNS가 빠르고, 업데이트 직후에는 ‘완고하게’ 느껴질 수 있습니다.
DNS 대시보드에 로그인하면 주로 몇 가지 레코드 유형을 편집하게 됩니다. 각 레코드는 인터넷에서 사람을 어디로 보낼지(웹), 이메일을 어디로 배달할지, 또는 소유권을 어떻게 검증할지 알려주는 작은 지시문입니다.
| 레코드 | 하는 일 | 간단한 예시 |\n|---|---|---|\n| A | 이름을 IPv4 주소로 지정 | example.com → 203.0.113.10 (웹 서버) |\n| AAAA | 이름을 IPv6 주소로 지정 | example.com → 2001:db8::10 |\n| CNAME | 한 이름을 다른 이름의 별칭으로 만듦 | www.example.com → example.com (둘 다 같은 곳으로 감) |\n| MX | 도메인의 이메일을 어디로 보낼지 지정 | example.com → mail.provider.com (우선순위 10) |\n| TXT | 기계가 읽을 수 있는 ‘노트’ 저장(검증, 이메일 정책) | example.com에 v=spf1 include:mailgun.org ~all 같은 SPF 레코드 |\n| NS | 도메인/존의 권한 있는 서버가 누구인지 표시 | example.com → ns1.dns-host.com |\n| SOA | 존의 “헤더”: 기본 NS, 관리자 연락처, 타이밍 값 포함 | example.com SOA는 ns1.dns-host.com 및 재시도/만료 타이머 포함 |\n
자주 보이는 DNS 오류는 다음과 같습니다:\n
example.com). 많은 DNS 제공업체가 이를 허용하지 않습니다. 루트 이름에는 NS와 SOA 같은 레코드도 있어야 하기 때문입니다. 루트를 호스트 이름으로 가리켜야 한다면 A/AAAA 레코드를 사용하거나 제공업체가 지원하면 ALIAS/ANAME 기능을 사용하세요.\nwww)에 CNAME과 A 레코드를 동시에 설정하지 마세요. 한 가지 방식을 선택하세요.\nmail.provider.com에 한 글자 잘못 써도 이메일이 깨질 수 있습니다; 점(.)의 유무나 잘못된 호스트 필드(@ vs www) 복사 실수도 흔한 장애 원인입니다.팀에게 DNS 지침을 공유한다면 위와 같은 작은 표를 문서(또는 런북)에 넣어 검토와 문제 해결을 훨씬 빠르게 할 수 있습니다.
DNS는 많은 조직에 책임을 분산했기 때문에 작동합니다. 이 분할 덕분에 제공업체를 바꾸고 설정을 변경해도 ‘인터넷에 허락을 받는’ 일이 필요하지 않습니다.
도메인 등록은 이름(example.com)을 일정 기간 사용할 권리를 사는 것입니다. 누군가가 그 이름을 쓰지 못하도록 예약하는 행위입니다.
DNS 호스팅은 그 이름이 가리킬 곳—웹사이트, 이메일 제공자, 검증 레코드 등—을 알려주는 설정을 운영하는 일입니다. 하나의 회사에서 도메인을 등록하고 다른 회사에서 DNS를 호스팅할 수 있습니다.
.com, .org, .uk 같은 최상위 도메인(TLD)을 운영하는 조직입니다. 각 TLD 아래 누가 어떤 이름을 보유하는지와 어떤 네임서버가 책임지는지를 공식 데이터베이스로 유지합니다.\n루트 서버는 DNS의 최상단에 위치합니다. 이들은 당신의 웹사이트 IP를 알지 못하며 도메인 레코드를 저장하지도 않습니다. 역할은 더 좁습니다: 리졸버에게 각 TLD를 어디서 찾을지 알려주는 것입니다(예: .com이 어디에서 처리되는지).
레지스트라에서 도메인의 네임서버를 설정하면 당신은 **위임(delegation)**을 생성하는 것입니다. 그러면 .com 레지스트리(그 권한 있는 서버들)는 example.com 쿼리를 당신이 선택한 네임서버로 가리킵니다.
그 순간부터, 그 네임서버들이 인터넷의 나머지에게 주는 답변을 통제합니다—다시 위임을 변경할 때까지.
DNS는 신뢰를 기반으로 합니다: 이름을 입력하면 그 답이 실제 서비스로 향한다고 가정합니다. 대부분의 경우 그대로지만, DNS는 공격자가 좋아하는 표적이기도 합니다. 왜냐하면 이름의 작은 변경만으로도 많은 사람을 잘못된 곳으로 보낼 수 있기 때문입니다.
클래식한 문제는 스푸핑 또는 캐시 중독입니다. 공격자가 리졸버를 속여 가짜 답변을 저장하게 하면, 사용자는 올바른 도메인을 입력했음에도 잘못된 IP로 전송될 수 있습니다. 결과는 피싱 페이지, 악성 다운로드, 트래픽 가로채기 등이 될 수 있습니다.
또 다른 문제는 레지스트라 수준의 도메인 하이재킹입니다. 누군가가 레지스트라 계정에 접근하면 네임서버나 DNS 레코드를 바꿔서 사이트 호스팅을 건드리지 않고도 도메인을 ‘탈취’할 수 있습니다.
일상적 위험은 잘못된 설정입니다. 잘못된 CNAME, 오래된 TXT 레코드, 틀린 MX 레코드가 로그인 흐름, 이메일 배달, 검증 체크를 망가뜨릴 수 있습니다. 이런 장애는 종종 “인터넷이 다운”처럼 보이지만 원인은 작은 DNS 편집에 있습니다.
DNSSEC는 DNS 데이터에 암호학적 서명을 추가합니다. 평이하게 말하면: DNS 응답이 전송 중 변경되지 않았고 실제로 도메인의 권한 있는 DNS에서 왔다는 것을 검증할 수 있게 해줍니다. DNSSEC는 DNS 쿼리를 암호화하거나 당신이 무엇을 조회하는지를 숨기진 않지만, 위조된 답변이 받아들여지는 것을 막는 데 많은 도움을 줍니다.
전통적 DNS 쿼리는 네트워크상에서 쉽게 관찰됩니다. **DNS-over-HTTPS(DoH)**와 **DNS-over-TLS(DoT)**는 기기와 리졸버 사이의 연결을 암호화해 도청과 일부 중간자 변조를 줄입니다. 이것들이 DNS를 “익명”으로 만들진 않지만, 누가 쿼리를 볼 수 있고 조작할 수 있는지를 바꿉니다.
레지스트라에서 MFA를 사용하고, 도메인/전송 잠금을 활성화하며, 누가 DNS를 편집할 수 있는지 제한하세요. DNS 변경을 운영 배포처럼 취급하세요: 검토를 요구하고 변경 로그를 보관하며 레코드나 네임서버 변경에 대한 모니터링/알림을 설정해 놀라운 변경을 빠르게 알 수 있게 하세요.
DNS는 ‘설정하고 잊어버리는’ 것으로 느껴질 수 있지만, 작은 변경 하나가 사이트나 이메일을 망가뜨릴 수 있습니다. 다행히 몇 가지 습관만 지키면 DNS 관리는 예측 가능해집니다—소규모 팀에도 적용됩니다.
반복할 수 있는 경량 프로세스를 시작하세요:\n
대부분의 DNS 문제는 복잡하지 않지만, 빠르게 알아차리기 어렵습니다.\n
앱을 자주 배포하는 팀이라면 DNS도 릴리스 프로세스의 일부가 됩니다. 예를 들어 Koder.ai 같은 플랫폼에서 채팅으로 앱을 빌드·배포하고 커스텀 도메인을 연결할 때도 동일한 기본 원칙을 따릅니다: 정확한 A/AAAA/CNAME 대상, 전환 중 합리적인 TTL, 잘못된 대상이 있을 경우를 대비한 명확한 롤백 경로 등.
도메인에서 이메일을 보낸다면 DNS가 메시지가 받은편지함에 도달하는지에 직접 영향을 줍니다.\n
사람이 읽기 쉬운 이름 덕분에 인터넷은 작은 연구 공동체를 넘어서 확장할 수 있었습니다. DNS를 공유 인프라로 취급하세요—초기의 작은 관리로도 사이트의 가용성과 이메일의 신뢰를 키울 수 있습니다.
DNS(도메인 네임 시스템)는 example.com 같은 사람이 기억하기 쉬운 이름을 93.184.216.34 같은 IP 주소로 바꿔서 당신의 기기가 어디에 연결할지 알게 해줍니다.
DNS가 없다면 각 사이트와 서비스의 숫자 주소를 직접 기억해야 할 것입니다.
초기 네트워크는 이름과 IP 주소를 매핑한 단일 공유 파일(HOSTS.TXT)에 의존했습니다.
네트워크가 커지면서 업데이트가 잦아지고 이름 충돌이 생기며 오래된 복사본 때문에 서비스 장애가 발생하는 등 관리가 불가능해졌습니다. DNS는 “전지구적 하나의 파일” 방식 대신 분산 시스템을 도입해 이 문제를 해결했습니다.
Paul Mockapetris는 1980년대 초에 DNS를 설계해 급성장하는 네트워크에서 이름 관리의 확장 문제를 해결했습니다.
핵심 아이디어는 *위임(delegation)*입니다: 책임을 여러 조직에 분산시켜 한 곳에 모든 마스터 목록이나 관리자가 병목이 되지 않도록 한 것입니다.
DNS 이름은 계층 구조로 구성되어 오른쪽에서 왼쪽으로 읽습니다:
www.example.com..comexample.comwww.example.com이 계층은 전 세계적 규모에서 위임과 관리를 실용적으로 만들어 줍니다.
재귀적(resolver) 조회자는 사용자를 대신해 답을 찾고 그것을 캐시합니다(일반적으로 ISP, 회사, 공개 제공자에서 운영).
권한 있는(authoritative) DNS 서버는 도메인의 레코드에 대한 진짜 출처입니다; 다른 곳을 검색하지 않고 자기 구역(zone)에 대해 최종 답을 제공합니다.
일반적인 조회 흐름은 다음과 같습니다:
.com) → 도메인의 권한 있는 서버.A/AAAA)를 반환합니다.**TTL(Time To Live)**은 리졸버가 DNS 답변을 얼마나 오래 캐시할 수 있는지를 알려줍니다.
“전파(propagation)”라고 불리는 현상은 대부분 서로 다른 캐시가 서로 다른 시점에 만료되는 결과입니다.
일반적으로 관리하는 레코드는 다음과 같습니다:
A / AAAA: 이름을 IPv4/IPv6 주소로 지정(웹 앱, 서버).등록(registration)은 example.com 같은 이름을 일정 기간 사용할 권리를 사는 것입니다(다른 사람이 못 쓰게 예약).
DNS 호스팅은 그 이름이 어디로 가야 하는지(웹, 이메일, 검증 레코드 등)를 세상에 알려주는 설정을 운영하는 것입니다.
한 회사에서 도메인을 등록하고 다른 회사에서 DNS를 호스팅하도록 섞어 쓸 수 있습니다. 레지스트라에서 도메인의 NS(네임서버) 설정을 바꾸면 됩니다.
DNS 장애의 일반적 원인:
MX, 충돌하는 레코드, 오타)실무 방어책:
CNAME: 한 호스트명을 다른 이름의 별칭으로 설정(보통 www에 사용).MX: 도메인으로 들어오는 이메일을 어디로 보낼지 지정.TXT: 소유권 확인 및 이메일 인증(SPF, DKIM, DMARC) 등에 사용.NS: 도메인에 대해 권한 있는 네임서버가 누구인지 지정.실용 규칙: 같은 호스트에 CNAME과 A 레코드를 동시에 두지 마세요.