DNSSEC의 작동 방식

DNSSEC의 가벼운 소개

DNSSEC은 기존 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 레코드를 검증합니다. KSK는 공개 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는 계층적 시스템이므로 구간이 독립적으로 작동하는 경우는 거의 없습니다. 또한, 키 서명 키는 자체적으로 서명하므로 추가적인 신뢰 기능이 없어 문제가 더욱 복잡해집니다. 이제 현재 구간의 신뢰를 상위 구간에 연결할 수 있는 방법이 필요합니다.

Delegation Signer Records

DNSSEC introduces a delegation signer (DS) record to allow the transfer of trust from a parent zone to a child zone. A zone operator hashes the DNSKEY record containing the public KSK and gives it to the parent zone to publish as a DS record.

Every time a resolver is referred to a child zone, the parent zone also provides a DS record. This DS record is how resolvers know that the child zone is DNSSEC-enabled. To check the validity of the child zone’s public KSK, the resolver hashes it and compares it to the DS record from the parent. If they match, the resolver can assume that the public KSK hasn’t been tampered with, which means it can trust all of the records in the child zone. This is how a chain of trust is established in DNSSEC.

Note that any change in the KSK also requires a change in the parent zone’s DS record. Changing the DS record is a multi-step process that can end up breaking the zone if it’s performed incorrectly. First, the parent needs to add the new DS record, then they need to wait until the TTL for the original DS record to expire before removing it. This is why it’s much easier to swap out zone-signing keys than key-signing keys.

Explicit Denial of Existence

If you ask DNS for the IP address of a domain that doesn’t exist, it returns an empty answer—there’s no way to explicitly say, “sorry, the zone you requested doesn’t exist.” This is a problem if you want to authenticate the response, since there’s no message to sign. DNSSEC fixes this by adding the NSEC and NSEC3 record types. They both allow for an authenticated denial of existence.

NSEC works by returning the “next secure” record. For example, consider a name server that defines AAAA records for api, blog, and www. If you request a record for store, it would return an NSEC record containing www, meaning there’s no AAAA records between store and www when the records are sorted alphabetically. This effectively tells you that store doesn’t exist. And, since the NSEC record is signed, you can validate its corresponding RRSIG just like any RRset.

Unfortunately, this solution allows anybody to walk through the zone and gather every single record without knowing which ones they’re looking for. This can be a potential security threat if the zone administrator was counting on the contents of the zone being private. You can read more about this problem in DNSSEC: Complexities and Considerations, as well as Cloudflare’s unique solution in DNSSEC Done Right.

신뢰의 고리

이제 구간 내에 신뢰를 확립했고 이를 상위 구간에 연결했습니다. 그렇다면 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을 자동으로 활성화할 수 있게 될 것입니다. 계속 업데이트됩니다.