#main-nav-header { display:none; }

DNSSEC의 작동 방식

DNS(Domain Name System)는 인터넷 전화번호부입니다. 컴퓨터는 이를 통해 어디에 정보를 보내고 어디에서 정보를 가져올지 알 수 있습니다. 하지만 DNS는 받는 모든 주소를 받아들이며 아무것도 묻지 않습니다.

이메일 서버는 DNS를 사용하여 메시지를 라우팅하기 때문에 이메일 서버는 DNS 인프라 내의 보안 문제에 취약합니다. 2014년 9월에 CMU의 연구자들은 Yahoo!, Hotmail, Gmail 서버를 통해 보내져야 할 이메일들이 악성 메일 서버를 통해 라우팅되는 것을 발견했습니다. 답을 받아들이기 전에 자격 증명을 확인하지 않는 DNS의 수십년 된 취약성을 공격자들이 이용한 것입니다.

이 해결책이 DNSSEC라고 하는 프로토콜로, 이는 인증을 통해 DNS 위에 신뢰라는 계층을 추가하는 것입니다. DNS 확인자가 blog.cloudflare.com을 찾는 경우, .com 이름 서버가 해결자를 도와 cloudflare에 대해 반환된 레코드를 확인하고 cloudflare는 블로그에 반환된 레코드 확인을 돕습니다. 루트 DNS 이름 서버는 .com 확인을 돕고, 루트가 게시한 정보는 루트 서명식을 포함한, 철저한 보안 절차를 거칩니다.

위임 서명자 레코드

DNSSEC는 위임 서명자(DS) 레코드를 도입해 상위 구간의 신뢰를 하위 구간으로 전송할 수 있습니다. 구간 오퍼레이터는 공개 KSK를 갖고 있는 DNSKEY 레코드를 해시 처리하고 이를 상위 구간에 주어 DS 레코드로 게시하게 합니다.

확인자가 하위 구간을 참조하게 될 때면 상위 구간도 DS 레코드를 제공합니다. 확인자는 이 DS 레코드로 인해 하위 구간에 DNSSEC이 활성화되어 있음을 알게 됩니다. 확인자는 하위 구간 공개 KSK의 유효성을 확인하기 위해 이를 해시 처리한 후 이를 상위 구간의 DS 레코드와 비교합니다. 이 두 가지가 일치한는 경우 확인자는 공개 KSK가 손상되지 않았다고 가정할 수 있습니다. 즉, 하위 구간의 모든 레코드를 신뢰할 수 있게 됩니다. 이렇게 하여 DNSSEC에서 신뢰의 고리가 확립됩니다.

특기할 사항은 KSK를 변경하면 상위 구간의 DS 레코드도 변경되어야 한다는 점입니다. DS 레코드 변경은 다단계 과정이며 부정확하게 수행하면 구간이 파괴될 수도 있습니다. 첫째, 상위 구간이 새 DS 레코드를 추가해야 하며 원래 DS 레코드의 TTL이 만료되기를 기다렸다가 삭제해야 합니다. 그러므로 구간 서명 키 교체가 키 서명 키 교체보다 훨씬 용이합니다.

명시적 존재 부정

존재하지 않는 도메인의 IP 주소를 DNS에 요청하면 아무 내용도 없는 응답을 받게 됩니다. "죄송하지만, 요청하신 구간이 존재하지 않습니다"라고 명시적으로 말하는 방법이 없는 것입니다. 이는 응답을 인증하고자 할 경우에 문제가 될 수 있습니다. 서명할 메시지가 없기 때문입니다. DNSSEC에서는 NSEC 및 NSEC3 레코드 유형을 추가하여 이를 해결합니다. 이 두 가지 중 어떤 것을 이용해도 존재 부정을 인증할 수 있습니다.

NSEC은 "다음 안전한" 레코드를 반환함으로써 작동합니다. 예를 들어, api, blog, www에 대한 AAAA 레코드를 정의하는 이름 서버를 생각해 보겠습니다. store에 대한 레코드를 요청한 경우, www가 들어 있는 NSEC 레코드가 반환됩니다. 레코드를 알파벳 순으로 정렬했을 때 store와 www 사이에 AAAA 레코드가 없다는 뜻입니다. 따라서 store가 존재하지 않는다는 것을 말한 것입니다. 또한, NSEC 레코드는 서명된 것이므로 다른 RRset과 마찬가지로 해당 RRSIG도 검증할 수 있습니다.

하지만 이러한 솔루션을 이용하게 되면 아무나 찾는 레코드가 무엇인지 모르는 상태에서 구간을 통과하면서 모든 레코드를 수집할 수 있게 됩니다. 구간 관리자가 해당 구간의 콘텐츠가 비공개 상태라고 믿고 있다면 이는 보안 위협이 될 수 있습니다. 이 문제에 대한 자세한 내용은 DNSSEC: 복잡성 및 고려 사항을 참조하시고, 제대로 수행한 DNSSEC에서 Cloudflare 고유의 솔루션에 대해 알아보시기 바랍니다.

신뢰의 고리

이제 구간 내에 신뢰를 확립했고 이를 상위 구간에 연결했습니다. 그렇다면 DS 레코드는 어떻게 신뢰할 수 있을까요? DS 레코드도 다른 RRset과 마찬가지로 서명됩니다. 즉, 상위 구간에 해당 RRSIG가 있습니다. 전체 검증 과정은 상위 공개 KSK에 도달할 때까지 반복됩니다. 이를 확인하기 위해서는 해당 상위 DS 레코드에 가야 하고 이런 식으로 신뢰의 고리를 올라가야 합니다.

하지만 마침내 루트 DNS 구간에 도달하면 문제가 발생합니다. 검증할 수 있는 기준이 되는 상위 DS 레코드가 없는 것입니다. 여기에서 글로벌 인터넷의 인간적인 측면을 볼 수 있습니다.

전 세계에서 선발된 몇 사람이 루트 서명식에 모여서, 매우 공개적으로, 감사 수준이 높은 상태에서 루트 DNSKEY RRset에 서명합니다. 이 서명식에서 루트 이름 서버의 공개 KSK 및 ZSK를 확인하는 데 이용할 RRSIG 레코드가 만들어집니다. 상위 DS 레코드가 있어 공개 KSK를 신뢰하는 것이 아니라, 비공개 KSK에 액세스하기 위한 보안 절차를 신뢰하므로 공개 KSK가 유효하다고 가정하는 것입니다.

상위 구간과 하위 구간의 신뢰를 확립하는 역량이 DNSSEC의 중요한 부분입니다. 이러한 고리의 어느 부분이든 깨진다면 요청한 레코드를 신뢰할 수 없습니다. 메시지 가로채기 공격으로 레코드 내용이 변경되어 그들이 원하는 IP 주소로 이동할 수 있기 때문입니다.

Summary

Similar to HTTPS, DNSSEC adds a layer of security by enabling authenticated answers on top of an otherwise insecure protocol. Whereas HTTPS encrypts traffic so nobody on the wire can snoop on your Internet activities, DNSSEC merely signs responses so that forgeries are detectable. DNSSEC provides a solution to a real problem without the need to incorporate encryption.

Cloudflare’s goal is to make it as easy as possible to enable DNSSEC. All Cloudflare customers can add DNSSEC to their web properties by flipping a switch to enable DNSSEC and uploading a DS record (which we'll generate automatically) to their registrar.: Learn more about how to get DNSSEC.

We’ve also published an Internet Draft outlining an automated way for registries and registrars to upload DS records on behalf of our customers. This will enable Cloudflare to automatically enable DNSSEC for our entire community. Stay tuned for updates.

수백만 개의 인터넷 자산이 신뢰합니다

사례 연구 보기