DNSSEC는 어떻게 작동하나요?

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

학습 목표

이 글을 읽은 후에 다음을 할 수 있습니다:

  • DNSSEC 정의
  • DNSSEC 작동 방식 이해
  • DNSSEC와 관련된 주요 개념 이해
  • DNSSEC로 영역을 보호하는 방법 알아보기
  • 신뢰의 고리가 어떻게 구축되는지 이해

글 링크 복사

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

해결책은 DNS에 인증을 추가하여 신뢰를 더하는 DNSSEC라는 프로토콜입니다. DNS 확인자가 blog.cloudflare.com를 찾는 경우, .com 네임 서버는 확인자가 Cloudflare에 대한 반환된 레코드를 검증하도록 지원하고, Cloudflare는 블로그에 대한 반환된 레코드를 검증하도록 지원합니다. 루트 DNS 네임 서버는 .com을 검증하는 데 도움을 주며, 루트가 게시한 정보는 루트 서명식을 포함한, 철저한 보안 절차를 거칩니다.


DNSSEC의 가벼운 소개

DNSSEC는 기존의 DNS 레코드에 암호화 서명을 추가하여 안전한 DNS 시스템을 만듭니다. 이러한 디지털 서명은 A, AAAA, MX, CNAME 등과 같은 일반적인 레코드 유형과 함께 DNS 네임 서버에 저장됩니다. 관련된 서명을 점검함으로써 요청된 DNS 레코드가 권한 있는 네임 서버에서 왔으며 중간자 공격으로 삽입된 가짜 레코드와 달리 전송 중 경로에서 변경되지 않았음을 확인할 수 있습니다.

서명 검증을 용이하게 하기 위해 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: 복잡성 및 고려 사항과 Cloudflare의 독자적인 해결책 ‘DNSSEC 올바르게 수행하기를 참조하세요.

신뢰의 고리

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

하지만 마침내 루트 DNS 영역에 도달하면 문제가 발생합니다. 검증할 수 있는 기준이 되는 상위 DS 레코드가 없다는 것입니다. 여기에서 전 세계 인터넷의 매우 인간적인 면모를 볼 수 있습니다.

전 세계에서 선발된 몇 사람이 루트 서명식에 모여서, 매우 공개적이고 철저히 감사되는 방식으로 루트 DNSKEY RRset에 서명합니다. 이 서명식에서는 루트 네임 서버의 공개 KSK와 ZSK를 검증할 수 있는 RRSIG 레코드를 생성합니다. 상위 DS 레코드가 있어 공개 KSK를 신뢰하는 것이 아니라, 비공개 KSK에 액세스하기 위한 보안 절차를 신뢰하므로 공개 KSK가 유효하다고 가정합니다.

상위 구간과 하위 구간의 신뢰를 확립하는 역량은 DNSSEC의 핵심 요소입니다. 체인의 어느 부분이라도 끊어지면, 중간자 공격자가 레코드를 변경하여 원하는 IP 주소로 리디렉션할 수 있기 때문에 요청하는 레코드를 신뢰할 수 없습니다.

등록 기관을 위한 DNSSEC

DNSSEC의 신뢰는 위에서 아래로 내려오는 방식이기 때문에(루트 영역이 .com 영역을 검증하고, .com 영역은 cloudflare.com 영역을 검증하는 방식) DNSSEC를 활성화하려면 웹 사이트 소유자가 등록 기관과 함께 DS 레코드를 업데이트해야 합니다.

이 부분은 문제가 될 수 있습니다. DS 레코드를 복사하여 붙여넣는 과정에서 사람의 실수가 발생할 수 있으며, 기술이 부족한 사용자에게는 복잡한 과정이 될 수 있습니다. Cloudflare는 DNSSEC를 최대한 쉽게 배포할 수 있게 만들고자 합니다.

Cloudflare가 등록 기관이나 레지스트리와 직접 통신할 수 있다면, Cloudflare의 모든 웹 사이트에 DNSSEC를 자동으로 활성화할 수 있으며 사람이 개입하지 않고도 키를 관리할 수 있습니다.

Cloudflare는 DNSSEC 롤아웃의 일환으로 Cloudflare는 .ca 레지스트리인 CIRA와 함께 인터넷 초안을 게시하여 Cloudflare 등의 DNS 운영자가 등록 기관 및 레지스트리와 통신하여 DNSSEC 관리를 자동화할 수 있는 프로토콜을 선보였습니다.

Cloudflare와 함께 모두가 DNSSEC를 더 쉽게 이용할 수 있게 만드세요

NIC Chile(.cl) 및 eNIC(.ee) 등 여러 레지스트리에서 지원을 추가할 계획을 이미 세우고 있습니다. 등록 기관이나 레지스트리에서 일하고 있고, 더 자세히 배우거나, 프로토콜 개발에 참여하거나, Cloudflare와의 통합을 더하는 데 관심이 있으시다면 dnssec-integration@cloudflare.com으로 이메일을 보내 연락해 주세요.

요약

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

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

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