DNS 보안과 CloudFront 캐시 운영
DNSSEC, DoH와 DoT, Route 53 라우팅, CloudFront 캐시 구조를 운영 관점에서 정리합니다. 특히 배포 후 구버전 콘텐츠, Failover 헬스 체크, SPA 새로고침 오류처럼 실제 장애로 이어지는 지점을 중심으로 봅니다.
Script Companion
오디오와 함께 스크립트 보기
- 01
이 문서는 DNS와 CDN을 단순한 이름 해석과 파일 배포가 아니라, 신뢰, 라우팅, 캐시, 장애 대응이 얽힌 운영 계층으로 다룹니다. 핵심 축은 DNSSEC의 검증 체인, DNS 질의 노출을 줄이는 DoH와 DoT, Route 53의 라우팅 정책, 그리고 CloudFront의 캐시 계층입니다. 여기서 중요한 것은 각각을 외워 두는 것이 아니라, 어떤 문제를 어느 계층에서 해결하는지 구분하는 감각입니다.
- 02
먼저 DNSSEC는 DNS 응답에 디지털 서명을 붙여 신뢰를 검증하는 방식입니다. 요약하면 DS, DNSKEY, RRSIG가 체인 오브 트러스트를 이루고, 응답이 중간에서 바뀌지 않았는지 확인하는 흐름입니다. DNS 자체가 이름을 주소로 바꾸는 계층이라면, DNSSEC는 그 응답을 믿어도 되는지 확인하는 보안 장치에 가깝습니다. 문서의 추천 리소스가 Kaminsky-style cache poisoning을 언급하는 것도, DNS 응답 신뢰의 한계를 배경으로 이해할 수 있습니다.
- 03
DNS 질의의 노출을 줄이는 방식으로는 DoH와 DoT가 정리되어 있습니다. 둘 다 DNS 평문 노출 문제를 다루지만, DoH는 443 포트를 사용하기 때문에 차단이 어렵다는 특징이 강조됩니다. 여기서 포인트는 두 기술을 단순히 암호화된 DNS라고 묶는 데서 끝나지 않는 것입니다. 운영 환경에서는 DNS 질의가 어디로 나가고, 네트워크 정책상 어떻게 관찰되거나 차단될 수 있는지가 함께 판단 대상이 됩니다.
- 04
Route 53은 DNS 응답을 고정된 한 값으로만 돌려주는 도구가 아니라, 여러 라우팅 정책을 제공하는 계층으로 정리됩니다. 단순 라우팅, 가중치 라우팅, 지연시간 라우팅, 지리 라우팅, Failover 라우팅이 있고, 여기에 헬스 체크가 결합됩니다. 즉 사용자를 어느 대상으로 보낼지, 장애가 났을 때 어느 대상으로 우회할지, 특정 지역이나 지연시간 조건을 어떻게 반영할지가 Route 53의 핵심 판단 지점입니다.
- 05
CDN 계층은 Edge, Regional Edge, Origin의 3계층 캐시로 이해할 수 있습니다. 사용자는 가까운 Edge에서 응답을 받고, 필요한 경우 Regional Edge를 거쳐 Origin까지 요청이 올라갑니다. CloudFront는 Distribution, Origin, Behavior, Cache Policy 구조로 정리됩니다. Distribution은 배포 단위이고, Origin은 원본 위치이며, Behavior와 Cache Policy는 어떤 요청을 어떻게 캐시하고 전달할지 결정하는 구성 요소입니다.
- 06
CloudFront 운영에서 가장 흔한 실패 중 하나는 배포 후에도 구버전 콘텐츠가 보이는 상황입니다. 문서의 원인은 두 가지입니다. 하나는 app.js 파일명에 콘텐츠 해시가 없어 새로 배포해도 파일명이 동일한 경우이고, 다른 하나는 캐시 무효화, Invalidation을 /app.js로 했지만 실제 캐시된 경로가 /app.js?v=1처럼 쿼리스트링을 포함한 경우입니다. 이때는 Versioned URL을 쓰고, index.html은 no-cache로 두는 조합이 베스트 프랙티스로 정리됩니다.
- 07
Route 53 Failover가 작동하지 않는 문제는 헬스 체크 요청이 서버에 닿지 않는 데서 시작할 수 있습니다. Route 53 헬스 체크는 54.183.0.0/16, 54.228.0.0/16 같은 특정 IP 대역에서 실행됩니다. 이 대역이 EC2 보안 그룹에서 차단되면 헬스 체크 요청이 막히고, Route 53은 타임아웃을 Healthy로 오해하거나 응답을 받지 못해 Unhealthy 판정이 지연될 수 있습니다. 따라서 DNS 장애 대응에는 TTL 사전 조정, 전파 확인 도구, 헬스 체크 IP 허용이 함께 들어갑니다.
- 08
SPA 배포에서는 새로고침 시 403이나 404가 나는 문제가 별도로 등장합니다. 원인은 SPA가 클라이언트 라우팅을 사용하기 때문입니다. 예를 들어 /users/123 경로에 해당하는 파일이 S3에 없으면, CloudFront가 S3에서 파일을 찾지 못하고 S3가 OAC 설정 시 403 또는 404를 반환합니다. 문서의 정리는 index.html no-cache, 정적 자산 해시 1년, CloudFront Function으로 SPA 라우팅을 처리하는 방향입니다.
- 09
정리하면 DNS와 CDN 운영은 보안 검증, 질의 보호, 라우팅 정책, 캐시 정책을 나누어 보는 문제입니다. DNSSEC는 DS, DNSKEY, RRSIG의 신뢰 체인을 다루고, DoH와 DoT는 DNS 평문 노출을 줄이며, Route 53은 라우팅과 헬스 체크를 묶습니다. CloudFront에서는 3계층 캐시와 Distribution, Origin, Behavior, Cache Policy 구조를 기준으로 보고, 캐시 무효화와 SPA 라우팅 문제는 배포 방식과 경로 설계에서 함께 점검해야 합니다.
같은 레이어
L7에서 이어 듣기
- 오디오 파일
- /podcasts/l7-dns-cdn.mp3