작은 DNS TTL 설정 실수가 불러온 캐시 폭풍과 스푸핑 취약점 실전 분석 및 방어 전략

사내 인프라의 도메인 레코드를 정비하는 작업 중에 특정 서비스 도메인의 TTL(Time To Live) 값이 5초로 설정된 것을 발견했습니다. 아무도 기억하지 못하는 과거 긴급 배포 시절의 설정이 그대로 남아있었던 것입니다. 처음에는 단순히 나쁜 설정이라고만 여겼으나 실제 트래픽 데이터를 분석하자 이 작은 숫자 하나가 외부 DNS 리졸버들에게 엄청난 부담을 주고 있었으며 동시에 잠재적인 보안 위협까지 내포하고 있음이 드러났습니다. TTL이 5초라는 것은 전 세계의 수많은 리졸버가 이 도메인의 IP 주소를 기억해두는 시간이 고작 5초라는 의미입니다. 그 이후에는 반드시 권한 있는 네임서버에 다시 물어봐야 합니다. 이 서비스의 접속자 수를 고려했을 때 권한 네임서버 입장에서는 초당 수천 건의 쿼리가 쏟아지는 셈이었고 이것이 불필요한 원거리 왕복 지연을 사용자 경험에 더하면서 동시에 네임서버 인프라에도 심각한 부하를 가하고 있었습니다. 캐싱의 이점이 제로에 가까운 상태로 운영되고 있었던 것입니다. 보안 관점에서의 위험은 더욱 심각했습니다. DNS 캐시 포이즈닝 공격은 리졸버가 특정 도메인에 대한 캐시를 비워내고 새로운 쿼리를 날리는 순간을 노립니다. TTL이 낮을수록 이 취약한 순간이 더 자주 찾아오게 되고 공격자가 위조된 응답으로 리졸버의 캐시에 악의적인 IP를 심을 기회가 기하급수적으로 늘어납니다. 방어 조치로 먼저 TTL을 프로덕션 환경의 표준인 300초로 상향 조정하여 쿼리 빈도 자체를 대폭 줄였습니다. 다음으로 DNSSEC(DNS Security Extensions)를 해당 도메인에 적용하여 응답 레코드에 디지털 서명을 덧붙임으로써 위조 응답을 리졸버가 자체적으로 검증 거부할 수 있도록 설정했습니다. 마지막으로 네임서버 앞단에 CDN 기반의 Anycast DNS 가속 레이어를 도입하여 TTL이 올라간 상황에서도 결국 유연한 배포 전환이 필요할 때는 CDN 레이어의 라우팅 정책을 건드리는 방식으로 민첩하게 대응할 수 있는 운영 체계를 갖추었습니다.