Domain IP Lookup

위조된 응답으로 경쟁에서 이기기

공격자

진짜 응답과 경쟁

위조된 응답

먼저 도착

리졸버 캐시

공유하는 모두에게 오염됨

보안

DNS 스푸핑과 캐시 포이즈닝: 실무 개요

읽는 시간 3분

DNS는 원래 응답이 실제로 응답했다고 주장하는 네임서버에서 왔는지 검증할 방법 없이 설계되었습니다. 이 허점이 스푸핑을 가능하게 합니다. DNS 질의를 가로채거나 응답 경쟁에서 앞설 수 있는 위치의 공격자는 피해자를 공격자가 고른 주소로 보내는 위조 응답을 되돌려 보낼 수 있으며, 정상 사이트를 사칭하는 악성 서버로 트래픽을 우회시키는 데 자주 쓰입니다.

캐시 포이즈닝: 같은 발상을 대규모로

캐시 포이즈닝은 같은 위조 응답 발상을 단일 피해자가 아니라 공유 리졸버를 겨냥해 적용합니다. 공격자가 널리 쓰이는 재귀 리졸버의 캐시에 위조된 응답을 끼워 넣는 데 성공하면, 그 리졸버를 이용하는 모든 사용자가 만료될 때까지 오염된 응답을 받게 됩니다. 한 번의 위조 성공이 같은 리졸버를 쓰는 모든 사람에 대한 공격으로 이어지며, 개별 질의를 하나하나 가로챌 필요도 없습니다.

최신 DNS는 이를 어떻게 방어하나요

방어 수단막아 주는 것보편적으로 배포되었나요?
소스 포트 / 질의 ID 무작위화진짜 응답이 도착하기 전에 위조 응답을 추측해 맞히는 것예, 2008년 이후 표준
DNSSEC권한 서버를 사칭하는 위조 응답아니요. 인터넷 전반에서 부분적으로만 도입됨
DNS-over-HTTPS / DNS-over-TLS질의 자체에 대한 경로상 가로채기늘고 있지만 모든 곳에서 기본값은 아님

이 방어책 중 어느 것도 보편적으로 배포되지는 않았으며, 특히 DNSSEC는 인터넷을 구성하는 도메인 전반에서 여전히 부분적으로만 도입되어 있습니다. DNSSEC가 적용되지 않는 경우에도, 잘 운영되고 보안을 중시하는 공개 리졸버를 사용하고, 예상 밖이거나 의심스러운 확인 결과는 독립적인 두 번째 리졸버에서 다시 확인하는 것이 현실적인 예방책입니다.

이 문제를 보는 시각을 바꾼 버그

캐시 포이즈닝은 2008년에 더 이상 이론적인 우려에 그치지 않게 되었습니다. 보안 연구원 댄 카민스키(Dan Kaminsky)가 당시 사용되던 거의 모든 DNS 리졸버에 영향을 주는 근본적인 결함을 공개했기 때문입니다. 공격자가 추측해야 하는 트랜잭션 ID와 소스 포트의 경우의 수가 충분히 작아서, 빠른 연결에서 몇 초 만에 무차별 대입이 가능했고, 단일 레코드가 아니라 도메인 전체에 대해 리졸버의 캐시를 오염시킬 수 있었습니다. 이 공개로 모든 주요 DNS 소프트웨어 공급업체가 이례적으로 조율된 동시 패치를 배포했고, 소스 포트 무작위화는 거의 하룻밤 사이에 표준이 되었으며, 위에 나열한 방어책이 현재의 형태로 존재하게 된 큰 이유가 되었습니다.

해결책이 20년 되었는데도 DNSSEC 도입이 더딘 이유

DNSSEC는 포트 무작위화만으로는 해결할 수 없는 근본적인 신뢰 문제를 훨씬 완전하게 해결합니다. 추측을 더 어렵게 만드는 것이 아니라 암호학적 증명이기 때문입니다. 도입이 느린 것은 그 가치에 대한 의구심보다 운영의 복잡성 때문입니다. 존에 올바르게 서명하고, 검증이 깨지지 않도록 일정에 맞춰 키를 교체하며, 루트에서 특정 도메인까지 신뢰 사슬을 온전히 유지하는 일은 서명되지 않은 A 레코드를 추가하는 것보다 훨씬 까다롭습니다. 이 과정에서 실수가 하나만 생겨도 이 시리즈의 다른 글에서 다룬 SERVFAIL 장애가 정확히 발생하며, 이는 DNS 전문 인력이 없는 소규모 도메인 운영자에게 그 자체로 도입을 망설이게 하는 요인입니다. “이론상 해결됨”과 “실제로 모든 곳에 배포됨” 사이의 격차는 보안 인프라 전반에서 흔하며, DNSSEC가 그 분명한 사례입니다.

도메인의 공개 DNS 주소를 확인해야 하나요? Domain IP Lookup 도구를 사용해 보세요.