#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의 가벼운 소개

DNSSEC은 기존 DNS 레코드에 암호화된 서명을 추가함으로써 안전한 DNS를 만듭니다. 이러한 디지털 서명은 DNS 이름 서버에 A, AAAA, MX, CNAME 등의 공통 레코드와 함께 저장됩니다. 관련 서명을 점검함으로써 요청한 DNS 레코드가 권위 있는 이름 서버에서 온 것인지 메시지 가로채기(man-in-the-middle) 공격에 의해 가짜 레코드가 추입되지 않고 중간에 수정되지 않고 온 것인지 확인할 수 있습니다.

DNSSEC은 서명 검증을 위해 새로운 DNS 레코드를 몇 가지 추가합니다.

RRSIG - 암호화된 서명이 들어 있습니다
DNSKEY - 공개 서명 키가 들어 있습니다
DS - DNSKEY 레코드의 해시가 들어 있습니다
NSEC, NSEC3 - DNS 레코도의 명시적 존재 부정에 적합합니다
CDNSKEY, CDS - 상위 구간의 DS 레코드 수정을 요청하는 하위 구간에 적합합니다.

이 글에서는 RRSIG, DNSKEY, DS 레코드 간의 상호 작용과 이들이 DNS 위에 신뢰의 계층을 더하는 방법을 설명하고자 합니다.

RRset

DNSSEC를 이용해 구간을 보안하는 첫 단계는 동일한 유형의 레코드를 자원 레코드 세트(RRset)로 묶는 것입니다. 예를 들어, 동일한 라벨(예: label.example.com)을 갖는 3개의 AAAA 레코드가 있다면, 이를 모두 하나의 AAAA RRset으로 묶습니다.

디지털 서명이 적용되는 것은 개별 DNS 레코드가 아니라 바로 이 전체 RRset입니다. 물론, 특정 구간에 있는 모든 AAAA 레코드를 요청하고 검증해야 하며 그 중 하나만을 검증하는 것이 아닙니다.

구간 서명 키

DNSSEC의 각 구간에는 구간 서명 키 쌍(ZSK)이 있습니다. 이 키의 비공개 부분은 구간 내의 개별 RRset에 디지털 서명을 하며 공개 부분은 서명을 확인합니다. 구간 오퍼레이터는 DNSSEC를 활성화하기 위해 비공개 ZSK를 사용하여 각각의 RRset에 대한 디지털 서명을 생성하고 이를 이름 서버에 RRSIG 레코드로 저장합니다. 이는 마치 "이것들은 내 DNS 레코드이며 내 서버에서 온 것이고 이들은 이렇게 보여야 합니다"라고 말하는 것과 같습니다.

하지만 이러한 RRSIG 레코드는 DNS 확인자에게 서명 검증 방법이 없다면 쓸모가 없습니다. 구간 오퍼레이터는 또한 공개 키를 이름 서버의 DNSKEY 레코드에 추가해 공개 ZSK를 이용할 수 있게 만들어야 합니다.

DNSSEC 확인자가 특정 레코드 유형(예: AAAA)를 요청하면 이름 서버는 해당 RRSIG도 반환합니다. 이제 확인자는 공개 ZSK가 있는 DNSKEY 레코드를 이름 서버에서 끌어올 수 있습니다. RRset, RRSIG, 공개 ZSK가 함께 응답을 검증할 수 있습니다.

DNSKEY 레코드의 구간 서명 키를 신뢰한다면 구간의 모든 레코드를 신뢰할 수 있습니다. 하지만 구간 서명 키가 손상되었다면 어떨까요? 공개 ZSK를 검증할 방법이 필요할 것입니다.

키 서명 키

구간 서명 키 이외에도 DNSSEC 이름 서버에는 키 서명 키(KSK)가 있습니다. KSK는 앞에서 ZSK가 RRset의 나머지 부분을 보안한 것과 완전히 동일한 방식으로 DNSKEY 레코드를 검증합니다. 이는 공개 ZSK(DNSKEY 레코드에 저장됨)에 서명하여 DNSKEY에 RRSIG를 만드는 것입니다.

공개 ZSK와 마찬가지로 이름 서버는 공개 KSK를 다른 DNSKEY 레코드에 게시하는데, 이를 통해 위에 표시된 것과 같은 DNSKEY RRset이 만들어집니다. 공개 KSK와 공개 ZSK 모두 비공개 KSK가 서명합니다. 이제 확인자는 공개 KSK를 이용해 공개 ZSK를 검증합니다.

이제 확인자의 검증은 이렇게 정리됩니다.

원하는 RRset을 요청하면 해당 RRSIG 레코드도 함께 반환됩니다.
공개 ZSK와 공개 KSK가 들어 있는 DNSKEY 레코드를 요청하면 DNSKEY RRset의 RRSIG도 함께 반환됩니다.
공개 ZSK로, 요청한 RRset의 RRSIG를 확인합니다.
공개 KSK로, DNSKEY RRset의 RRSIG를 확인합니다.

물론, DNSKEY RRset 및 해당 RRSIG 레코드는 캐시할 수 있으므로 DNS 이름 서버에 불필요한 요청이 지속적으로 몰려오지는 않습니다.

별도의 구간 서명 키와 키 서명 키를 이용하는 이유는 무엇일까요? 다음 절에서 살펴 보겠지만, 오래되거나 손상된 KSK를 교체하는 일이 쉽지 않기 때문입니다. 이에 비해 ZSK를 교체하는 일은 훨씬 용이합니다. 이렇게 함으로써, 서버의 보안을 손상하지 않으면서 ZSK의 크기를 줄여 서버가 각 응답에 함께 보낼 데이터 양을 줄일 수 있는 것입니다.

이제 구간 내에서 신뢰를 확립했지만, DNS는 계층적 시스템이므로 구간이 독립적으로 작동하는 경우는 거의 없습니다. 또한, 키 서명 키는 자체적으로 서명하므로 추가적인 신뢰 기능이 없어 문제가 더욱 복잡해집니다. 이제 현재 구간의 신뢰를 상위 구간에 연결할 수 있는 방법이 필요합니다.

위임 서명자 레코드

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 주소로 이동할 수 있기 때문입니다.

요약

HTTPS와 마찬가지로 DNSSEC은 안전하지 않은 프로토콜 위에 인증된 답을 활성화함으로써 보안 계층을 더합니다. HTTPS는 트래픽을 암호화하여 이동 구간 중에 누구도 당사자의 인터넷 활동을 스누핑할 수 없게 하지만, DNSSEC은 단순히 서명 응답을 추가해 위조가 발각되게 하는 것입니다. DNSSEC은 암호화를 도입할 필요 없이 실제 문제에 대한 해결책을 제시합니다.

Cloudflare는 DNSSEC 활성화를 최대한 쉽게 만드는 것이 목표입니다. 현재, Cloudflare의 유료 요금제 고객은 DNSSEC 활성화 스위치를 올리고 DS 레코드(Cloudflare가 자동으로 생성합니다)를 등록 기관에 올리기만 하면, 웹 자산에 DNSSEC을 추가할 수 있습니다. DNSSEC을 확보하는 방법에 대한 자세한 내용을 확인하세요.

또한, Cloudflare는 레지스트리 및 등록 기관이 고객을 대신해 DS 레코드를 업로드하는 자동화된 방법을 개괄하는 인터넷 초안을 게시하였습니다. 이를 통해 Cloudflare는 전체 커뮤니티를 대상으로 DNSSEC을 자동으로 활성화할 수 있게 될 것입니다. 계속 업데이트됩니다.