DNS 설정 완벽 가이드 — A레코드, CNAME, 네임서버 쉽게 설명

핵심 요약

>

- DNS(Domain Name System)는 도메인 주소를 IP 주소로 변환해주는 인터넷의 '전화번호부'다. - 레코드 종류마다 역할이 다르다: A레코드(IPv4 주소 연결), AAAA레코드(IPv6), CNAME(도메인 별칭), MX(이메일 라우팅), TXT(소유권 인증·SPF 등). - 네임서버(NS) 변경은 도메인 등록 기관에서 하고, 레코드 편집은 DNS 공급자(Cloudflare, Route 53 등) 패널에서 한다. - TTL이 낮을수록 변경 사항이 빠르게 반영되지만, 서버 부하가 높아진다. - DNS 전파(Propagation)는 전 세계 서버에 퍼지는 데 최대 48시간이 걸릴 수 있다. - 직접 설정 전, DNS Lookup 도구로 현재 레코드를 먼저 확인하자.

---

DNS란 무엇인가? 왜 필요한가?

우리가 브라우저에 www.example.com을 입력하면 컴퓨터는 그 주소 뒤에 숨어있는 실제 IP 주소(예: 93.184.216.34)를 찾아야 한다. 사람은 숫자로 된 IP를 외우기 어렵기 때문에, 도메인 이름을 IP 주소로 변환해주는 시스템이 필요하다. 이것이 바로 DNS(Domain Name System)다.

DNS는 전 세계에 분산된 수천 개의 서버로 구성되어 있으며, 계층 구조를 이룬다.

1. 루트 DNS 서버 — 최상위. 전 세계 13개 클러스터가 운영.
2. TLD(최상위 도메인) 서버 — .com, .kr, .io 등 도메인 종류별 서버.
3. 권한 있는(Authoritative) DNS 서버 — 특정 도메인의 레코드를 실제로 보관하는 서버. Cloudflare, Route 53, 가비아 DNS 등이 여기에 해당.
4. 재귀(Recursive) DNS 리졸버 — 사용자의 인터넷 공급자(ISP) 또는 Google(8.8.8.8), Cloudflare(1.1.1.1) 등이 제공하는 중간 서버. 사용자 대신 위 계층을 탐색해 결과를 캐시한다.

이 구조 덕분에 전 세계 수십억 개의 도메인 조회가 빠르게 처리된다.

---

DNS 레코드 종류별 완전 해부

DNS 레코드는 도메인에 대한 다양한 정보를 저장하는 항목이다. 종류마다 역할이 완전히 다르므로 하나씩 살펴보자.

A 레코드 (Address Record)

가장 기본적인 레코드. 도메인을 IPv4 주소에 연결한다.

• 루트 도메인(example.com)과 서브도메인(www, blog, api 등) 모두에 설정 가능하다.
• 하나의 도메인에 여러 A 레코드를 등록하면 라운드로빈 로드 밸런싱 효과를 낼 수 있다.

AAAA 레코드

A 레코드와 동일하지만 IPv6 주소를 가리킨다. IPv6 주소는 2606:2800:220:1:248:1893:25c8:1946처럼 길고 복잡한 형태다. IPv6 지원이 필요한 서비스라면 A 레코드와 함께 AAAA 레코드를 병행 설정해야 한다.

CNAME 레코드 (Canonical Name)

도메인을 다른 도메인에 연결하는 별칭(alias) 레코드다. IP 주소가 아니라 도메인 이름을 값으로 갖는다.

CNAME의 핵심 제약: 루트 도메인(example.com, @)에는 CNAME을 사용할 수 없다. 루트 도메인에는 반드시 A 또는 AAAA 레코드를 써야 한다. 단, Cloudflare 같은 서비스는 내부적으로 처리해주는 CNAME Flattening 기능을 제공한다.

MX 레코드 (Mail Exchange)

이메일을 수신하는 메일 서버를 지정한다. 우선순위(Priority) 숫자가 낮을수록 먼저 시도된다.

Google Workspace, Microsoft 365 등의 이메일 서비스를 연결할 때 반드시 설정해야 한다.

TXT 레코드 (Text Record)

도메인에 텍스트 형태의 정보를 저장한다. 주로 다음 용도로 활용된다.

• 도메인 소유권 인증: Google Search Console, GitHub Pages 등에서 요구.
• SPF(Sender Policy Framework): 이메일 발신 서버를 명시해 스팸 차단에 활용.

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

• DKIM: 이메일 디지털 서명 키 등록.
• DMARC: 이메일 인증 정책 선언.

NS 레코드 (Name Server)

해당 도메인의 DNS를 관리하는 서버가 어디인지 알려준다. 도메인 등록 기관(레지스트라)에서 변경하며, 모든 레코드의 '주인'을 정하는 가장 상위 설정이다.

SOA 레코드 (Start of Authority)

DNS 존(Zone)의 관리 정보를 담는 레코드. 직접 편집할 일은 거의 없지만 시리얼 번호, 새로고침 간격 등을 포함한다.

---

네임서버란 무엇이며 어떻게 설정하는가?

네임서버의 역할

네임서버(Name Server)는 특정 도메인의 모든 DNS 레코드를 최종적으로 보관하고 응답하는 서버다. 예를 들어, Cloudflare를 DNS 공급자로 선택하면 아래와 같은 네임서버 주소가 할당된다.

ava.ns.cloudflare.com
rick.ns.cloudflare.com

네임서버 변경 절차

1. 도메인 등록 기관(가비아, 후이즈, Namecheap, GoDaddy 등) 관리 페이지에 로그인한다.
2. 해당 도메인 설정에서 네임서버 변경 항목을 찾는다.
3. 기존 네임서버를 지우고 새 DNS 공급자(예: Cloudflare)가 제공한 주소로 교체한다.
4. 저장 후 전파 완료까지 최대 48시간 대기한다.

주의: 네임서버를 변경하면 기존 DNS 공급자의 모든 레코드가 무효화된다. 새 공급자 패널에서 레코드를 미리 옮겨둬야 서비스 중단을 방지할 수 있다.

---

TTL이란? 얼마로 설정해야 하는가?

TTL(Time To Live)은 DNS 레코드가 리졸버 캐시에 저장되는 시간(초 단위)이다. 예를 들어 TTL이 3600이면 1시간 동안 캐시된다.

전략적 TTL 관리법:

• 서버 이전 예정 1~2일 전에 TTL을 300초로 낮춰두면, 실제 이전 시 변경 사항이 빠르게 전파된다.
• 이전이 완료되고 안정화되면 TTL을 다시 3600~86400으로 올린다.

---

DNS 전파란 무엇인가? 왜 시간이 걸리는가?

DNS를 변경해도 전 세계 사용자에게 즉시 반영되지 않는 이유는 캐시 때문이다. 각 리졸버 서버는 이전 레코드를 TTL이 만료될 때까지 보관한다. 따라서:

• TTL이 3600이었다면 변경 후 최대 1시간까지 구 주소로 접속될 수 있다.
• 국가별·ISP별로 캐시 갱신 시점이 다르므로, 일부 지역에선 먼저 반영되고 일부는 늦게 반영된다.
• 전 세계 완전 전파까지 최대 48시간을 예상해야 한다.

현재 전파 상태는 DNS Lookup 도구에서 직접 조회해 확인할 수 있다.

---

Cloudflare와 AWS Route 53 실전 설정 예시

Cloudflare에서 A레코드 추가하기

1. Cloudflare 대시보드 → 도메인 선택 → DNS 탭 클릭.
2. Add record 버튼 클릭.
3. 타입: A, 이름: @(루트) 또는 www, IPv4 주소: 서버 IP 입력.
4. Proxy status: 오렌지 구름(프록시 활성화) 또는 회색 구름(DNS only) 선택.

- 프록시 활성화 시 Cloudflare CDN·DDoS 보호가 적용된다.

1. TTL은 프록시 활성화 시 자동(Auto)으로 고정된다.
2. Save 클릭.

CNAME Flattening 활용: Cloudflare는 루트 도메인(@)에도 CNAME처럼 동작하는 설정이 가능하다. 이름에 @, 타입에 CNAME을 선택하고 대상 도메인을 입력하면 내부적으로 A 레코드로 변환해준다.

AWS Route 53에서 레코드 추가하기

1. AWS 콘솔 → Route 53 → Hosted zones → 도메인 선택.
2. Create record 클릭.
3. Record name: 서브도메인 입력(루트면 비워둠).
4. Record type: A, CNAME, MX 등 선택.
5. Value: IP 또는 대상 도메인 입력.
6. TTL: 초 단위 입력(기본 300).
7. Routing policy: Simple(기본), Weighted, Latency, Failover 등 선택 가능.
8. Create records 클릭.

Route 53은 별칭(Alias) 레코드를 지원한다. AWS 리소스(ALB, CloudFront, S3 정적 웹사이트 등)를 루트 도메인에 연결할 때 유용하며, 추가 비용 없이 사용 가능하다.

---

DNS 설정 시 흔히 하는 실수와 해결법

실수 1: 루트 도메인에 CNAME 사용 시도

문제: example.com(루트)에 CNAME을 설정하면 RFC 표준 위반이며, 많은 DNS 공급자가 이를 거부하거나 MX·TXT 레코드와 충돌을 일으킨다.

해결: 루트 도메인엔 A 레코드를 사용하거나, Cloudflare의 CNAME Flattening 또는 Route 53의 Alias 레코드를 활용한다.

실수 2: 네임서버 변경 후 레코드를 옮기지 않음

문제: 네임서버를 Cloudflare로 바꾸면 이전 DNS 공급자의 레코드는 더 이상 적용되지 않아 사이트·이메일이 중단된다.

해결: 네임서버 변경 전에 새 공급자 패널에서 모든 레코드(A, MX, TXT 등)를 미리 복사해 입력해둔다.

실수 3: TTL을 높게 유지한 채 서버 이전

문제: TTL이 86400(24시간)인 상태로 서버 IP를 바꾸면 최대 24시간 동안 구 서버로 트래픽이 향한다.

해결: 이전 최소 24~48시간 전에 TTL을 300초로 낮춘 뒤 이전 작업을 진행한다.

실수 4: MX 레코드에 IP 주소 입력

문제: MX 레코드의 값에는 반드시 도메인명이 들어가야 한다. IP를 직접 입력하면 이메일 전송이 실패한다.

해결: MX 레코드 값에는 aspmx.l.google.com처럼 도메인명을 정확히 입력한다.

실수 5: SPF 레코드 중복 등록

문제: TXT 레코드로 SPF를 두 개 이상 등록하면 이메일 인증이 실패한다. SPF는 도메인당 하나만 허용된다.

해결: 여러 메일 서비스를 쓴다면 하나의 SPF 레코드에 include로 합쳐야 한다.

• 잘못된 예: SPF TXT 레코드 2개 등록
• 올바른 예: v=spf1 include:_spf.google.com include:sendgrid.net ~all

실수 6: www와 루트 도메인을 별개로 처리하지 않음

문제: example.com에만 A 레코드를 설정하고 www.example.com을 설정하지 않으면 www로 접속하는 사용자는 오류를 만난다.

해결: 루트 도메인과 www 서브도메인을 모두 설정한다. www CNAME을 루트 도메인으로 향하게 하거나, 둘 다 같은 IP로 A 레코드를 설정한다.

---

FAQ

Q1. DNS 변경 후 바로 반영이 안 되는데, 내 설정이 잘못된 건가요?

아니다. DNS 전파는 캐시 구조 때문에 시간이 걸린다. TTL 값과 각 리졸버의 캐시 상태에 따라 다르지만, 일반적으로 수분에서 수 시간, 길게는 48시간까지 기다려야 한다. DNS Lookup 도구로 조회해 레코드 자체가 올바르게 등록됐는지 먼저 확인하자. 도구에서 정상으로 보인다면 기다리면 된다.

Q2. A레코드와 CNAME 중 어떤 걸 써야 하나요?

서버의 IP를 직접 가리킬 때는 A 레코드, 다른 도메인(예: GitHub Pages, Shopify, Vercel 등 외부 서비스)을 가리킬 때는 CNAME을 사용한다. 루트 도메인(example.com)에는 A 레코드가 원칙이며, 서브도메인에서는 두 가지 모두 상황에 맞게 선택한다.

Q3. Cloudflare 프록시(오렌지 구름)를 켜면 어떤 점이 달라지나요?

프록시를 켜면 방문자의 트래픽이 Cloudflare 서버를 경유한다. 이 경우 실제 서버 IP가 외부에 노출되지 않고, Cloudflare의 CDN 캐싱·DDoS 보호·SSL 자동 적용 혜택을 받는다. 단, 일부 애플리케이션(예: FTP, 커스텀 포트 서비스)은 프록시 모드와 호환되지 않을 수 있다.

Q4. 네임서버는 최소 몇 개를 등록해야 하나요?

DNS 안정성을 위해 최소 2개 이상의 네임서버를 등록해야 한다. 하나가 장애를 일으켰을 때 나머지가 응답할 수 있도록 이중화하는 것이 원칙이다. 대부분의 DNS 공급자는 기본적으로 2~4개의 네임서버를 제공한다.

Q5. TTL은 낮을수록 좋은 건가요?

낮은 TTL은 변경 사항이 빠르게 반영되는 장점이 있지만, 리졸버가 캐시 없이 매번 권한 있는 서버에 질의하므로 DNS 서버 부하와 응답 지연이 증가할 수 있다. 평상시에는 3600(1시간) 정도가 적절하고, 변경 작업 전에만 임시로 낮추는 전략이 효율적이다.

Q6. 이메일이 갑자기 수신이 안 됩니다. DNS 문제일 수 있나요?

충분히 가능하다. 이메일 수신 문제는 MX 레코드 누락 또는 오류가 주요 원인 중 하나다. DNS Lookup 도구에서 도메인의 MX 레코드를 조회해 올바른 메일 서버가 등록되어 있는지 확인하자. 또한 최근에 네임서버를 변경했다면, 새 DNS 공급자 패널에 MX 레코드가 옮겨졌는지 점검해야 한다.

Q7. 서브도메인은 몇 개까지 만들 수 있나요?

기술적 제한은 거의 없다. api.example.com, blog.example.com, dev.example.com 등 필요한 만큼 생성할 수 있다. 다만 각 서브도메인마다 별도 DNS 레코드가 필요하며, 와일드카드 레코드(*.example.com)를 사용하면 모든 서브도메인을 하나의 대상으로 일괄 처리할 수도 있다.

---

정리: DNS 설정 체크리스트

아래 순서로 점검하면 대부분의 DNS 문제를 예방할 수 있다.

• [ ] 루트 도메인과 www 서브도메인에 A 레코드(또는 CNAME) 모두 설정됨
• [ ] 이메일 서비스 사용 시 MX 레코드 등록 및 우선순위 확인
• [ ] SPF, DKIM, DMARC TXT 레코드 등록 (이메일 발신 신뢰도 향상)
• [ ] 루트 도메인에 CNAME 사용하지 않음
• [ ] 네임서버 변경 전 새 공급자에 레코드 미리 이전 완료
• [ ] 서버 이전 전 TTL을 300초 이하로 낮춤
• [ ] SPF 레코드가 도메인당 하나만 존재하는지 확인
• [ ] DNS Lookup 도구로 설정 결과 검증

DNS는 한 번 익혀두면 어떤 플랫폼, 어떤 서비스를 쓰더라도 흔들리지 않는 기반 지식이 된다. 처음에는 낯설게 느껴지지만, 레코드 종류와 역할만 파악하면 대부분의 설정은 어렵지 않게 해결할 수 있다.