DNS 캐시 포이즈닝 (재귀 리졸버, DNSSEC, 다층 방어)

DNS 캐시 포이즈닝

브라우저가 사이트를 찾는 법, 재귀 리졸버의 역할

주소창에 URL을 입력하는 순간 눈에 보이지 않는 과정이 시작됩니다. OS가 먼저 로컬 DNS 캐시를 뒤지고, 거기 없으면 재귀 리졸버(Recursive Resolver)에 질의합니다. 여기서 재귀 리졸버란 사용자 대신 루트 네임서버부터 차례로 질의를 이어가며 최종 IP 주소를 찾아오는 중간 대리인입니다. 흔히 ISP나 구글(8.8.8.8), Cloudflare(1.1.1.1) 같은 공개 DNS 서버가 이 역할을 합니다.

리졸버는 루트 네임서버(Root NS)에 먼저 물어 TLD 네임서버 주소를 받고, 그 TLD 서버에서 권한 있는 네임서버(Authoritative NS) 주소를 받은 뒤, 거기서 최종 IP를 가져옵니다. 이 IP는 TTL(Time To Live) 값과 함께 캐시에 저장됩니다. TTL이란 해당 캐시 항목이 유효한 시간을 초 단위로 명시한 값으로, 이 시간이 지나기 전까지는 리졸버가 같은 질의에 대해 캐시된 결과를 그대로 돌려줍니다.

저도 이 구조를 머릿속으로만 알고 있다가, 실제로 체감한 건 사내 개발 환경에서였습니다. 특정 내부 도메인에 접속하면 간헐적으로 외부 IP로 튀는 현상이 있었는데, 처음엔 서버 문제인 줄 알았습니다. nslookup과 dig 명령어로 확인해보니 일부 클라이언트의 DNS 캐시에 잘못된 IP가 박혀 있었고, 원인은 내부 DNS 서버의 TTL을 지나치게 길게 설정한 것이었습니다. 그날 이후로 TTL 값 하나를 얼마나 신중하게 다뤄야 하는지 몸으로 익혔습니다.

DNS 캐시 포이즈닝, 어떻게 캐시가 오염되는가

DNS 캐시 포이즈닝(Cache Poisoning)은 공격자가 재귀 리졸버의 캐시에 위조된 DNS 응답을 주입하는 공격입니다. 쉽게 말해 리졸버가 정답을 받기 전에 가짜 정답을 먼저 집어넣는 것입니다. 리졸버가 이를 진짜로 받아들이면, 그 이후 같은 도메인을 질의하는 모든 사용자가 공격자가 지정한 악성 IP로 연결됩니다.

2011년 브라질 ISP 대규모 포이즈닝 사건에서는 수백만 명의 인터넷 사용자가 악성 사이트로 리다이렉트되었습니다. 그리고 MyEtherWallet 사건은 BGP 하이재킹과 DNS 포이즈닝이 결합된 형태로, 사용자는 HTTPS 경고도 제대로 인지하지 못한 채 가짜 지갑 사이트에 자산을 넘겼습니다. 2025년에는 BIND 9 재귀 리졸버에서 고심각도 취약점인 CVE-2025-40778이 발견되어 즉각적인 패치가 요구되기도 했습니다(출처: ZeroFox). BIND 9는 전 세계적으로 가장 널리 사용되는 DNS 서버 소프트웨어인 만큼, 이 취약점의 파급 범위는 생각보다 훨씬 컸습니다.

공격이 성립하는 이유는 전통적인 DNS가 UDP 기반이고 응답 인증 수단이 없기 때문입니다. 리졸버는 올바른 트랜잭션 ID와 포트 번호가 맞으면 응답을 신뢰합니다. 공격자가 충분히 빠르게 위조 응답을 보내면 그게 캐시에 저장되고, 실제 권한 있는 서버의 정상 응답은 이미 늦어버립니다.

DNSSEC, 설정해보니 생각보다 까다로웠습니다

DNSSEC(DNS Security Extensions)는 DNS 레코드에 암호화 서명을 추가해 응답의 진위를 검증하는 보안 확장 표준입니다. 여기서 DNSSEC란 권한 있는 서버가 자신의 응답에 디지털 서명을 붙이고, 리졸버가 그 서명을 검증해 위조 여부를 판별하는 구조입니다. 서명이 맞지 않으면 응답 자체를 거부하기 때문에, 캐시 포이즈닝을 암호화 수준에서 차단할 수 있는 사실상 유일한 수단으로 꼽힙니다(출처: RFC 4033, 4034, 4035).

저도 직접 실습해봤는데, 솔직히 이건 예상 밖이었습니다. 도메인에 DNSSEC를 활성화하고 레지스트라에 DS 레코드를 등록하는 것까지는 했는데, 설정 직후 일부 리졸버에서 도메인이 아예 해석되지 않았습니다. DS 레코드란 상위 DNS 계층에 등록해두는 서명 검증용 키 해시로, 이게 전파되는 데 시간이 필요합니다. 전파(propagation) 시간을 충분히 두지 않은 채 성급하게 확인하다가 "내가 도메인을 날린 건가" 싶어 식은땀이 났습니다.

그것보다 더 골치 아팠던 건 키 롤오버(Key Rollover) 절차였습니다. DNSSEC는 서명 키를 주기적으로 교체해야 하는데, 이 절차를 제때 하지 않으면 키가 만료되어 오히려 도메인이 접근 불가 상태가 됩니다. 직접 운영하면서 느낀 건, DNSSEC는 강력하지만 운영 복잡도가 높아서 소규모 팀이 직접 관리하기엔 부담이 크다는 것입니다. Cloudflare나 AWS Route 53의 관리형 DNSSEC 서비스를 쓰면 키 교체 등을 자동화해주니 현실적으로 훨씬 나은 선택입니다.

단일 방어책은 없다, 다층 방어 체계를 구성해야 합니다

DNSSEC가 강력한 건 맞지만, 제가 직접 운영하면서 느낀 한계가 있습니다. DNSSEC는 서명 검증만 할 뿐, DNS 질의 내용 자체를 암호화하지 않습니다. 즉 누가 어떤 도메인을 조회하는지는 여전히 평문으로 드러납니다. 여기에 더해, 아직도 많은 TLD와 도메인이 DNSSEC를 배포하지 않은 상태라 생태계 전체가 보호받지 못합니다.

그래서 DNS 보안은 다층 방어로 접근해야 합니다. 제가 실제로 점검하는 항목을 기준으로 정리하면 다음과 같습니다.

• DNSSEC 활성화: 서명 검증을 통한 캐시 포이즈닝 차단
• 소스 포트 무작위화(Source Port Randomization): DNS 요청 포트를 무작위로 바꿔 공격자의 스푸핑 난이도를 높임. 단, NAT 장비가 포트를 고정시킬 수 있으므로 네트워크 구성도 함께 점검해야 합니다
• DoH/DoT 적용: DNS over HTTPS 또는 DNS over TLS를 사용해 질의 내용 자체를 암호화해 전송 중 변조를 방지
• 재귀 질의 제한: 신뢰할 수 있는 클라이언트에만 재귀 서비스를 허용해 오픈 리졸버로 악용되는 것을 차단
• TTL 전략적 설정: 변경 가능성이 높은 레코드는 TTL을 짧게, 안정적인 레코드는 길게 설정해 캐시 효율과 보안을 균형 있게 유지
• 정기적 DNS 레코드 검증 모니터링: 권한 서버의 응답과 리졸버의 응답을 자동화 도구로 주기적으로 비교해 이상 징후를 조기에 탐지

DNSSEC 하나로 모든 걸 해결하려는 시각도 있는데, 저는 그렇게 보지 않습니다. DNSSEC는 위변조 방지이고, DoH/DoT는 프라이버시 보호이며, 소스 포트 무작위화는 추측 공격 방어입니다. 각 레이어가 서로 다른 위협을 막습니다. 하나가 뚫렸을 때 나머지가 버텨주는 구조가 진짜 방어입니다.

DNS는 인터넷의 전화번호부라는 비유를 자주 씁니다. 전화번호부가 조작되면 아무리 정확한 번호를 외워도 엉뚱한 곳으로 연결됩니다. 저는 이 문제를 사내 개발 환경의 작은 설정 오류로 처음 실감했지만, MyEtherWallet 사건을 보면 그게 실제 피해로 얼마나 직결되는지 알 수 있습니다. DNSSEC를 설정하고, DoH 또는 DoT를 켜고, TTL과 모니터링 체계까지 갖추는 것. 그게 지금 당장 시작할 수 있는 가장 현실적인 출발점입니다.

---

참고:

• ZeroFox — CVE-2025-40778 DNS Cache Poisoning: https://www.zerofox.com/blog/zerofoxs-proactive-defense-dns-cache-poisoning-threats/
• OneUptime — DNS Cache Poisoning Detection: https://oneuptime.com/blog/post/2026-03-20-diagnose-dns-cache-poisoning/view
• Multilogin — DNS Cache Poisoning Defense: https://multilogin.com/glossary/dns-cache-poisoning-defense/
• WhoisFreaks — Understanding DNS Poisoning: https://whoisfreaks.com/resources/blog/understanding-dns-poisoning-risks-and-prevention-strategies
• LogicMonitor — DNS Poisoning Attacks: https://www.logicmonitor.com/deep-dive/dns-monitoring/dns-poisoning-attacks
• RFC 4033, 4034, 4035 (DNSSEC): https://tools.ietf.org/html/rfc4033