DNS 튜닝 가이드: TTL, CNAME 체인, 프리패치 최적화

페이지가 느린 이유, 서버만 탓할 순 없습니다. DNS 조회(이름 해석) 는 첫 바이트 이전에 반드시 거치는 단계라 미세한 최적화만으로도 TTFB·LCP가 눈에 띄게 개선됩니다. 이 글은 운영자가 바로 적용할 수 있는 TTL 설계, CNAME 체인 단축, 프리패치 전략을 실무 중심으로 정리합니다.

1) TTL 설계: 오래 vs 짧게의 트레이드오프

TTL(Time To Live) 은 레코드가 리졸버 캐시에 유지되는 시간입니다. 길면 쿼리 수가 줄고, 짧으면 변경이 빨라집니다. 핵심은 변경 가능성에 따라 차등 적용하는 것.

정적 자원 도메인(static, img, cdn): 변경 드뭄 → A/AAAA/CNAME TTL 1~24시간 권장
애플리케이션 메인 도메인(www, api): 롤백·장애 우려 → 60~300초(1~5분)
메일·인증(MX, TXT, _acme-challenge): 운영 패턴에 맞춰 10~60분
Failover/트래픽 우회: 헬스체크 기반이면 30~60초로 단축해 탐지 속도 확보

팁

배포 전 TTL 단계적 단축(예: 24h→1h→5m), 배포 안정화 후 다시 늘리면 변경 민첩성+쿼리 비용을 모두 잡습니다.
레코드 쪼개기: 자주 바뀌는 항목만 별도 서브도메인으로 분리하면 전체 TTL을 짧게 가져갈 필요가 없습니다.

2) CNAME 체인: 짧게, 납득 가능하게

CNAME 체인은 www → cdn.example → vendor.net → edge.vendor.net 처럼 여러 번 이름을 따라가야 하는 상황입니다. 체인이 길수록 왕복(RTT) 과 캐시 미스 위험이 커집니다.

원칙
1. 1~2단계 이내로 유지 (가능하면 단일 CNAME).
2. 벤더가 또 다른 벤더로 위임하는 “CNAME of CNAME” 구조는 계약·설정 단계에서 직결 A/AAAA 또는 단일 CNAME으로 요구.
3. 체인을 줄일 수 없다면 상위 노드 TTL을 길게, 하위 레코드는 벼락치기 변경이 가능한 값으로 관리.
운영 팁
- Cloud/보안 프록시(WAF, Bot 방어, CDN)를 연동할 때는 최종 엣지의 네임을 바로 가리키는 CNAME을 받고 문서화합니다.
- 주기적으로 dig +trace 또는 RUM의 DNS 단계 지연을 점검해 서드파티 체인 길이를 관리하세요.

3) 프리패치·프리커넥트: 초기 왕복을 미리 깎기

브라우저는 힌트를 주면 네트워크 준비를 렌더 블로킹 없이 앞당깁니다.

DNS Prefetch: 도메인 이름만 미리 해석외부 리소스(이미지, 폰트, 측정 스크립트)가 초기 화면에 필요하다면 효과가 큽니다.
<link rel="dns-prefetch" href="//img.example.com"> <link rel="dns-prefetch" href="//fonts.gstatic.com">
Preconnect: DNS+TCP(+TLS)까지 미리RTT가 큰 해외·모바일 구간에서 체감 개선이 확실합니다. 다만 불필요한 커넥션은 낭비이므로 상위 폴드(Above-the-fold) 에 즉시 필요한 도메인만.
<link rel="preconnect" href="https://cdn.example.com" crossorigin> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
Prefetch/Preload: 리소스 자체를 미리 당기기
- preload는 렌더에 꼭 필요한 핵심 리소스(LCP 이미지, 크리티컬 폰트)에만.
- prefetch는 곧 필요할 가능성 높은 리소스(다음 페이지 영웅 이미지 등)에 사용.

우선순위: preconnect > dns-prefetch (효과 크기 기준). 필요 도메인만 엄선하세요.

4) IPv6·Anycast·EDNS 최적화 포인트

AAAA 레코드 제공: 모바일·해외망에서 IPv6 경로가 더 짧은 경우가 많습니다. 가능하면 A와 AAAA 동시 제공.
Anycast DNS: 글로벌 응답 지연을 크게 낮춥니다. 비용이 허용된다면 권위 DNS부터 Anycast 제공하는 사업자를 고려하세요.
EDNS Client Subnet(ECS): 일부 CDN은 클라이언트 위치 기반으로 근접 엣지를 응답합니다. 개인정보·캐시 단편화 이슈가 있어 벤더 안내에 맞춰 제한적으로 사용.

5) 모니터링: 숫자로 관리해야 튜닝이 오래 간다

RUM: DNS 단계 시간, 첫 요청 도메인 수, 실패율을 국가·통신사·디바이스로 분리 추적
Synthetic: 주요 리전에 에이전트를 두고 A/AAAA/CNAME 응답 시간, 체인 단계 수를 주기 체크
알람 기준
- DNS p95가 150ms+(해외 250ms+)로 상승 시 원인 조사
- 체인 단계가 3단계 이상 감지되면 경고
- TTL 변경 후 NXDOMAIN/ SERVFAIL 급증 감시

6) 실전 체크리스트(바로 적용)

도메인별 역할 분리: 메인, 정적, 이미지, API, 서드파티를 명시적으로 구분
TTL 매트릭스 작성: 각 도메인/레코드에 “기본 TTL / 배포 전 TTL”을 표준화
CNAME 체인 인벤토리: 체인 길이·소유자·연락 창구를 문서화하고 분기마다 점검
프리커넥트 최소셋: LCP·폰트·필수 CDN 2~4개만 선별 적용, 나머지는 dns-prefetch
IPv6 On: A와 AAAA를 함께 제공하고 방화벽/로깅 경로 확인
벤더 변경 시 플레이북: 사전 TTL 단축→변경→유효성 검사→TTL 복원 순서 고정

7) 자주 묻는 질문(FAQ)

Q. TTL을 아주 짧게 두면 가장 빠른가요?
A. 캐시 히트가 떨어져 오히려 느려질 수 있습니다. 변경 주기가 짧은 레코드에만 짧은 TTL을 쓰세요.

Q. dns-prefetch와 preconnect를 같이 써도 되나요?
A. preconnect가 상위 개념이라 중복은 불필요합니다. preconnect만 유지하세요.

Q. CNAME 체인은 꼭 나쁜가요?
A. 1단계 수준은 일반적입니다. 문제는 복수 벤더가 연속 위임하며 3단계 이상 늘어날 때입니다.

마무리

DNS는 “설정하고 잊는” 영역이 아닙니다. TTL을 상황별로 다르게, CNAME 체인을 짧게, 프리패치/프리커넥트를 엄선 적용하면 DNS 단계 지연이 확 줄고 초기 렌더 안정성이 올라갑니다. 배포 전 TTL 단축과 RUM·Synthetic의 지표 기반 운영까지 묶어 지속 가능한 성능 개선 루프를 만드세요.

몽글이 소소한 이야기