도메인을 설정하고 나서 “왜 아직 안 보여요?”라는 질문이 가장 흔합니다. DNS가 어떻게 동작하고 전파에 왜 시간이 걸리는지 알면, 기다리는 시간이 답답하지 않고 문제 진단도 빨라집니다.

도메인 → DNS → 호스팅 서버 연결 흐름

브라우저에 example.com을 입력하면 일어나는 일

핵심 단계는 다섯 가지입니다.

① 브라우저: "example.com이 뭐지?"
② 로컬 DNS(ISP/8.8.8.8): 캐시 확인 → 없으면 외부 조회
③ 루트 → TLD → 권한 DNS 순차 조회로 IP를 알아냄
④ 로컬 DNS가 브라우저에 IP 반환 (캐시)
⑤ 브라우저가 그 IP로 HTTP/HTTPS 요청

이 모든 게 평소엔 0.1초 안에 끝나서 우리가 의식하지 못할 뿐입니다.

DNS의 4계층 구조

1) 루트 DNS (.)

  • 13개 서버군 (실제로는 anycast로 전 세계 수백 노드)
  • “어디서 .com을 찾을지” 알려줌
  • 운영: ICANN 산하 + 협력 기관

2) TLD DNS (.com, .net, .kr 등)

  • 해당 TLD의 권한 DNS 위치를 알려줌
  • 운영: 레지스트리 (예: .com은 VeriSign)

3) 권한 DNS (Authoritative)

  • 도메인 소유자가 지정한 네임서버
  • 실제 A/AAAA/MX/TXT 레코드 보유
  • 운영: 도메인 등록업체 또는 별도 DNS 제공자(Cloudflare, Route53 등)

4) 재귀 DNS (Recursor)

  • ISP가 운영하거나 공개 DNS(8.8.8.8, 1.1.1.1)
  • 위 3계층을 돌며 답을 찾고 캐시
  • 사용자에게 가장 가깝게 배치됨

DNS 레코드의 종류

타입 역할 예시 값
A 도메인 → IPv4 203.0.113.10
AAAA 도메인 → IPv6 2001:db8::10
CNAME 다른 도메인의 별명 www → example.com
MX 메일 서버 위치 mail.example.com (우선순위 10)
TXT 임의 텍스트 (SPF·DKIM·인증) “v=spf1 ip4:…”
NS 권한 네임서버 지정 ns1.example.com
CAA SSL 인증서 발급 제한 “letsencrypt.org”
SRV 서비스 위치 _sip._tcp 등
PTR IP → 도메인 (역방향) mail.example.com

가장 자주 다루는 것은 A·CNAME·MX·TXT 네 가지입니다.

TTL이란

각 DNS 레코드에는 TTL (Time-To-Live) 이 있습니다. “이 응답을 몇 초 동안 캐시해도 되는가”를 의미합니다.

  • TTL 60 (1분) → 캐시 짧음, 변경이 빨리 반영됨, 권한 DNS 부하 큼
  • TTL 3600 (1시간) → 균형, 일반적
  • TTL 86400 (24시간) → 캐시 오래, 변경 반영 느림

중요: 큰 변경을 앞두고 있다면 변경 며칠 전에 TTL을 짧게 낮춰두는 것이 좋습니다. 변경 시점에는 이미 짧은 TTL이 전 세계에 캐시되어, 변경 반영이 빨라집니다.

변경 5일 전: TTL 86400 → 3600으로 낮춤 (구 TTL이 남아 있으니 다음 갱신부터 적용)
변경 1일 전: TTL 3600 → 300으로 낮춤
변경 당일: 레코드 변경 (300초 내 반영)
변경 후 1일: TTL 다시 3600으로 복귀

“DNS 전파”가 시간이 걸리는 진짜 이유

DNS는 전 세계가 한 번에 갱신되는 시스템이 아닙니다. 각 재귀 DNS는 이전 응답을 TTL 만큼 캐시해 두고, 만료될 때까지 갱신하지 않습니다.

예시 — 변경을 12:00에 했고 TTL이 3600(1시간)이라면:

  • 캐시 만료가 11:30이었던 서버 → 12:30에 갱신 (30분 지연)
  • 캐시 만료가 11:55이었던 서버 → 12:55에 갱신 (55분 지연)
  • 캐시 만료가 12:01이었던 서버 → 13:01에 갱신 (1시간 지연)

결국 TTL만큼은 무조건 기다려야 합니다. 게다가 일부 ISP·기기는 TTL을 무시하고 더 오래 캐시하기도 합니다.

현실적 기대치:

TTL 80% 전파 99% 전파
60s 5분 30분
300s 30분 2시간
3600s 2시간 6~24시간
86400s 12시간 24~48시간

흔한 트러블슈팅

Q. dig은 새 IP를 보여주는데 브라우저는 옛 IP로 가요

  • 운영체제 또는 브라우저 캐시 잔여 가능성
  • 윈도우: ipconfig /flushdns
  • macOS: sudo dscacheutil -flushcache
  • 크롬: chrome://net-internals/#dns → Clear host cache
  • 모바일: 와이파이 껐다 켜기

Q. 일부 사람만 보이고 일부는 안 보입니다

  • ISP별 DNS 캐시 차이 — TTL 만료까지 기다리거나
  • 사용자가 1.1.1.1 / 8.8.8.8 같은 공개 DNS로 전환하면 바로 보일 수 있음

Q. 변경했는데 24시간 이상 그대로입니다

  • 권한 DNS에 실제로 변경됐는지 확인 (NS 직접 dig)
  • 도메인이 만료되어 등록업체의 주차 페이지로 돌아갔을 가능성
  • DNSSEC 설정에 문제가 있을 수 있음
# 권한 NS 직접 조회 (캐시 우회)
dig @ns1.cloudflare.com example.com A

DNS 변경 작업 체크리스트

이사·서버 교체 등 큰 DNS 변경 시:

  • 며칠 전 TTL을 300 이하로 낮춤
  • 변경 직전 백업 (현재 레코드 스크린샷 / 텍스트 저장)
  • 변경 후 권한 DNS에서 직접 확인 (dig @ns1)
  • 외부 모니터링 도구로 전파 추적 (whatsmydns.net)
  • 48시간 후 TTL 원상복구
  • 옛 서버는 최소 7일 유지 (옛 캐시 따라간 사용자 위해)

DNS 관리 도구 추천

도메인 등록업체 기본 DNS는 기능이 단순한 경우가 많습니다. 본격적으로 운영한다면 별도 DNS 서비스를 권합니다.

서비스 특징
Cloudflare DNS 무료, 빠름, DNSSEC 자동, 변경 즉시
AWS Route 53 강력한 라우팅 정책, 헬스체크
Google Cloud DNS 안정적, Google 인프라
가비아 DNS 한국어, 한국 등록업체 통합
BIND 자체 운영 무료지만 운영 부담

이 중 가장 가성비·성능 모두 좋은 게 Cloudflare입니다. 무료 플랜만으로도 대부분 충분합니다.

자주 묻는 질문

Q. 도메인을 옮겨도 DNS 레코드는 따라오나요?

  • 자동으로는 안 옵니다. 새 등록업체에서 다시 입력해야 합니다.

Q. 네임서버를 바꾸면 즉시 적용되나요?

  • TLD에서 새 NS로 안내하기까지 보통 1~2시간, 완전 전파는 24~48시간.

Q. CNAME과 ALIAS는 뭐가 다른가요?

  • CNAME은 표준이지만 루트 도메인(@)에는 사용 불가
  • ALIAS/ANAME은 일부 제공자의 확장으로, 루트에도 사용 가능

Q. DNS over HTTPS(DoH) / DNS over TLS(DoT)는 뭔가요?

  • DNS 쿼리 자체를 암호화해 도청·변조를 막는 방식. 브라우저·OS에서 점점 기본화되는 추세입니다.

마무리

DNS는 한 번 이해해 두면 호스팅·이메일·SSL 등 거의 모든 인터넷 작업에서 기준이 됩니다. TTL을 미리 낮추기·권한 DNS를 직접 확인하기·변경 후 모니터링 세 가지만 기억하면 큰 사고는 피할 수 있습니다.

TCP-80.NET의 호스팅 서비스는 DNS 설정 가이드를 텔레그램 @tcp80net으로 한국어 안내합니다. 도메인 신청은 일본 도메인 등록 페이지에서 가능합니다.