🌍
DNS 도메인 설정은 어떻게 반영되나?
onamae.com 같은 사이트에서 도메인 설정하면 실제로 어떤 일이 일어나는가
DNS는 인터넷에서 가장 기본적이면서도 중요한 인프라입니다. 우리가 브라우저에 "example.com"을 입력하면, 실제로는 복잡한 DNS 조회 과정을 거쳐 해당 서버의 IP 주소를 찾아갑니다. onamae.com, Cloudflare, Route 53 같은 DNS 관리 서비스에서 레코드를 설정하면, 이 정보가 전 세계 DNS 서버에 전파(propagation)되어 누구나 해당 도메인으로 접속할 수 있게 됩니다.
구조 다이어그램
DNS 계층 구조 (도메인 조회 흐름)
👤
사용자 (브라우저)
myapp.com
↓
🔍
DNS Resolver
예: 8.8.8.8 (Google)
↓ 1단계
🌐
루트 서버 (.)
전 세계 13개
.com은 여기로 →
↓ 2단계
📂
TLD 서버 (.com)
Verisign
NS 정보 반환
↓ 3단계
🏢
권한 네임서버
ns1.onamae.com
A: 76.76.21.21 반환
↓
🖥️
웹 서버 (Vercel)
76.76.21.21
onamae.com에서 설정하면 일어나는 일
1
도메인 구매
onamae.com → Verisign(.com 레지스트리)에 등록 요청
2
네임서버(NS) 설정
기본 NS(onamae) 사용 또는 Cloudflare/Route 53으로 변경
3
DNS 레코드 추가
A myapp.com → 76.76.21.21
CNAME www.myapp.com → cname.vercel-dns.com
CNAME www.myapp.com → cname.vercel-dns.com
4
DNS 전파 (Propagation)
전 세계 DNS 서버에 전파 (A 레코드: 수분~수시간 / NS 변경: 최대 48시간)
# dig 명령어로 DNS 조회 확인
$ dig myapp.com +short
76.76.21.21
$ dig myapp.com
;; ANSWER SECTION:
myapp.com. 300 IN A 76.76.21.21
^^^ TTL (초)
76.76.21.21
$ dig myapp.com
;; ANSWER SECTION:
myapp.com. 300 IN A 76.76.21.21
^^^ TTL (초)
핵심 포인트
•
DNS는 "계층적 위임" 구조 — 루트 → TLD → 권한 NS 순으로 책임 분산
•
onamae.com에서 설정하는 것은 "권한 네임서버의 레코드"를 편집하는 것
•
TTL을 낮추면 전파 속도 ↑, 하지만 DNS 서버 부하 ↑ — 변경 후 다시 올릴 것
동작 흐름
1
사용자가 브라우저에 myapp.com 입력
2
OS가 로컬 DNS 캐시 확인 → 없으면 설정된 DNS 리졸버(예: 8.8.8.8)에 질의
3
DNS 리졸버가 루트 서버(.)에 질의 → .com TLD 서버 주소 획득
4
.com TLD 서버에 질의 → myapp.com의 권한 네임서버(NS) 주소 획득
5
권한 네임서버(예: ns1.onamae.com)에 질의 → A 레코드(IP 주소) 획득
6
DNS 리졸버가 결과를 TTL 시간만큼 캐시 후 브라우저에 IP 반환
7
브라우저가 해당 IP(예: 76.76.21.21)로 HTTP/HTTPS 접속
장점
- ✓ 전 세계 어디서든 도메인명으로 접속 가능
- ✓ IP 주소 변경 시 DNS 레코드만 수정하면 됨 (서비스 무중단)
- ✓ CNAME으로 유연한 트래픽 라우팅 가능
- ✓ TXT 레코드로 도메인 소유권 증명, SPF/DKIM 설정 가능
단점
- ✗ DNS 전파에 최대 48시간 소요 (특히 NS 변경 시)
- ✗ TTL 캐시로 인해 즉시 반영 불가
- ✗ DNS 스푸핑/캐시 포이즈닝 공격 가능 (DNSSEC 미적용 시)
- ✗ 레지스트라 장애 시 도메인 설정 변경 불가
사용 사례
커스텀 도메인 연결 (Vercel, Netlify, Heroku 등)
메일 서버 설정 (Google Workspace, Microsoft 365)
CDN 연결 (Cloudflare, AWS CloudFront)
SSL 인증서 도메인 인증 (DNS-01 챌린지)
서브도메인 분리 (api.myapp.com, blog.myapp.com)