DNSKEY와 DS 레코드: DNSSEC 핵심 개념

अपडेट किया गया 1 माह पहले

DNS는 맹목적인 신뢰 위에 구축되었습니다.

"example.com은 어디에 있나요?"라고 물으면, 여러분의 컴퓨터는 그 질문을 네트워크로 보내고 돌아오는 답을 그대로 믿습니다. 검증 없이. 진위 확인 없이. 그냥 신뢰 — 낯선 사람에게 길을 물어보고 아무 의심 없이 따라가는 것처럼요.

공격자들은 이것을 악용합니다. DNS 응답을 가로채서 거짓 정보로 교체하고, 여러분이 방문하려던 사이트와 똑같이 생긴 악성 서버로 리다이렉트합니다. DNS가 확인할 수단을 제공하지 않았기 때문에, 여러분의 컴퓨터는 차이를 알 수 없습니다.

DNSSEC는 이것을 바꿉니다. DNS에 암호학적 서명을 추가하며, DNSKEY와 DS 레코드는 그 서명이 검증되는 방식의 기초입니다. 이 둘이 함께 신뢰 체인을 만들어, 여러분의 컴퓨터가 DNS 응답이 진짜라는 것을 수학적으로 증명할 수 있게 해줍니다.

신뢰 체인

인터넷의 DNS는 계층 구조입니다. 맨 위에는 루트 존이 있습니다. 그 아래에는 .com, .org, .net 같은 최상위 도메인(TLD)이 있습니다. 그 아래에는 여러분이 실제로 사용하는 도메인들이 있습니다: example.com, google.com, 여러분 회사의 도메인.

DNSSEC는 이 계층 구조를 따라가는 암호학적 증명 체인을 만듭니다. 루트 존은 .com을 보증합니다. .com 존은 example.com을 보증합니다. 그리고 example.com은 자신의 레코드 — 여러분이 찾고 있는 실제 IP 주소 — 를 보증합니다.

이 체인의 모든 링크가 유효하면, 최종 답은 신뢰할 수 있습니다. 어떤 링크든 끊어지면 — 누락된 서명, 유효하지 않은 증명, 일치하지 않는 해시 — 전체가 실패합니다. 여러분의 컴퓨터는 거짓 정보를 신뢰하는 대신 답을 거부합니다.

이것이 페일-세이프(fail-secure) 설계입니다. DNSSEC는 위조된 답을 주느니 차라리 아무 응답도 하지 않습니다.

DNSKEY 레코드: 공개 키

서명된 모든 DNS 존에는 서명 검증에 사용되는 공개 키가 담긴 DNSKEY 레코드가 있습니다. example.com이 DNS 레코드에 서명할 때, 그 서명은 example.com의 공개 키로만 검증할 수 있습니다. 그 키는 DNSKEY 레코드에 저장됩니다.

example.com. 3600 IN DNSKEY 257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF+KkxLbxILfDLUT0rAK9iUzy1L53eKGQ==

각 구성 요소:

257 — 이것이 키 서명 키(KSK)임을 나타내는 플래그 (잠시 후 자세히 설명)
3 — 프로토콜 필드, DNSSEC에서는 항상 3
13 — 알고리즘 번호 (SHA-256을 사용하는 ECDSA P-256)
긴 문자열 — Base64로 인코딩된 실제 공개 키

리졸버가 서명(RRSIG 레코드에 저장됨)과 함께 DNS 레코드를 수신하면, DNSKEY를 사용하여 그 서명을 검증합니다. 수식이 성립하면 레코드는 진본입니다.

두 가지 키, 두 가지 역할

DNSSEC는 두 가지 유형의 키를 사용하며, 그 이유는 실용적입니다.

**존 서명 키(ZSK, Zone Signing Key)**는 실제 DNS 레코드 — A 레코드, MX 레코드, 존의 모든 레코드 — 에 서명합니다. 존이 다시 서명될 때마다 지속적으로 사용됩니다. 자주 사용되기 때문에, 보안 관행상 자주 교체해야 합니다 — 보통 몇 달에 한 번씩.

**키 서명 키(KSK, Key Signing Key)**는 한 가지 역할만 합니다: DNSKEY 레코드 세트 자체에 서명하는 것입니다. KSK는 두 키 모두를 보증하며(자기 자신 포함), 덜 자주 사용되기 때문에 교체 주기도 길어집니다 — 보통 1년에 한 번 정도.

왜 굳이 두 개의 키를 쓸까요? 키를 변경할 때 무슨 일이 일어나는지를 생각해보면 답이 나옵니다.

ZSK를 교체할 때는, 새 키를 생성하고 존에 다시 서명한 뒤 DNSKEY 레코드를 업데이트하면 됩니다. 외부 세계는 알 필요가 없습니다. 상위 존이 신뢰하는 키인 KSK는 변경되지 않았으니까요.

KSK를 교체할 때는, 상위 존을 업데이트해야 합니다. 조율이 필요하고, 시간이 걸리며, 문제가 생길 수 있는 구간이 생깁니다. 키를 분리함으로써, 그런 조율이 필요한 횟수를 최소화하는 겁니다.

DS 레코드: 체인의 연결 고리

여기서 핵심 질문이 생깁니다: 왜 누구든 example.com의 DNSKEY를 신뢰해야 할까요? 누구든 example.com의 권한이 있다고 주장하는 DNSKEY 레코드를 게시할 수 있는데 말이죠.

답은 DS 레코드입니다. DS 레코드는 상위 존에 저장된 하위 존 KSK의 해시입니다. .com 존은 example.com의 KSK 해시를 담은 DS 레코드를 보유합니다. 이것이 신뢰 체인의 연결 고리를 만듭니다.

example.com. 3600 IN DS 12345 13 2 1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF

각 필드:

12345 — 어떤 DNSKEY를 참조하는지 빠르게 식별하는 키 태그
13 — DNSKEY와 일치하는 알고리즘 번호
2 — 다이제스트 유형 (SHA-256)
16진수 문자열 — 하위 존 DNSKEY의 해시

리졸버가 example.com을 검증하려 할 때, 먼저 .com에서 DS 레코드를 가져옵니다(.com의 DNSKEY로 검증할 수 있습니다). 그런 다음 example.com의 DNSKEY를 가져와서 확인합니다: 이 키를 해시했을 때 DS 레코드의 다이제스트가 나오나요? 그렇다면 키는 정당합니다. 상위 존이 보증한 것입니다.

체인을 따라가 보기

실제 검증 과정을 따라가 봅시다. www.example.com을 검증하고 싶다고 가정합니다.

먼저, 리졸버는 무언가를 신뢰해야 합니다. 그것은 루트 존의 공개 키 — 신뢰 앵커(trust anchor) — 입니다. 이 키는 별도의 안전한 경로를 통해 리졸버에 배포되며, 드물게만 업데이트됩니다. 루트 키는 DNSSEC가 그냥 믿어달라고 요청하는 유일한 것입니다. 나머지는 모두 증명할 수 있습니다.

루트 키를 신뢰한 상태에서:

루트 → .com: 리졸버는 루트에 .com의 DS 레코드를 요청합니다. 루트는 이 응답에 서명합니다. 리졸버는 루트의 DNSKEY로 서명을 검증합니다. 이제 .com KSK의 신뢰할 수 있는 해시가 확보됩니다.
.com → example.com: 리졸버는 .com에 DNSKEY를 요청하고, 루트에서 받은 DS 레코드와 일치하는지 검증한 뒤, example.com의 DS 레코드를 요청합니다. .com 존이 이 응답에 서명합니다. 이제 리졸버는 example.com KSK의 신뢰할 수 있는 해시를 확보했습니다.
example.com → www: 리졸버는 example.com에 DNSKEY를 요청하고, .com에서 받은 DS 레코드와 일치하는지 검증한 뒤, www.example.com의 A 레코드와 서명을 요청합니다. example.com의 ZSK로 서명을 검증합니다 (ZSK는 KSK가 보증하고, KSK는 DS 레코드가 보증합니다).

모든 단계는 이전 단계에 의존합니다. 어느 링크 하나라도 끊어지면 검증은 실패합니다.

키를 교체해야 할 때

키는 영원하지 않습니다. 알고리즘은 시간이 지나면서 약해집니다. 키가 유출될 수도 있습니다. 모범 사례는 특별한 위협이 없더라도 주기적으로 교체하는 것입니다.

ZSK 롤오버는 존 내부에서 이루어집니다. 일반적인 방식: 새 키를 이전 키와 함께 게시하고, 캐시가 업데이트될 때까지 기다리고, 이전 서명을 유지하면서 새 키로 서명을 시작하고, 다시 기다린 후, 이전 키와 서명을 제거합니다. 점진적으로 전환하면 리졸버가 항상 필요한 것을 갖게 됩니다.

KSK 롤오버는 상위 존의 DS 레코드를 업데이트해야 하기 때문에 더 까다롭습니다. 안전한 방식: 이전 KSK와 새 KSK를 모두 게시하고, 두 DS 레코드를 상위 존에 제출하고, 전 세계적인 전파를 기다리고 (DNS 캐시는 어디에나 있기 때문에 시간이 걸립니다), 그런 다음 이전 KSK와 해당 DS 레코드를 제거합니다.

타이밍 하나가 모든 것을 결정합니다. 새 DS 레코드가 전파되기 전에 이전 KSK를 제거하면, 캐시된 데이터를 여전히 쓰는 사용자들의 검증이 깨집니다. 자동화된 도구가 이제 대부분을 처리하지만, 무언가 잘못됐을 때는 그 메커니즘을 이해하는 게 결정적으로 중요합니다.

증명의 구조

DNSSEC는 신뢰 위에 구축된 시스템에 증명을 덧붙입니다. DNSKEY 레코드는 서명을 검증하는 공개 키를 담습니다. 상위 존에 저장된 DS 레코드는 하위 존 키의 해시를 담아 그 키들을 체인에 연결합니다.

두 키 체계는 교체를 감당할 수 있게 만들기 위해 존재합니다. ZSK는 원할 때마다 바꾸면 됩니다. KSK를 바꿀 때는 상위 존과 조율해야 합니다.

체인은 루트에서 시작해 계층 구조의 각 레벨을 따라 아래로 흐릅니다. 하나의 신뢰할 수 있는 루트 키. 수십억 개의 도메인, 모두 증명 가능. 바로 이 구조입니다 — 원래부터 아무것도 증명하도록 설계되지 않은 프로토콜 위에 쌓아 올린 수학적 증명.

DNSKEY와 DS 레코드에 관해 자주 묻는 질문

DS 레코드가 DNSKEY와 일치하지 않으면 어떻게 되나요?

전체 도메인에 대한 DNSSEC 검증이 실패합니다. 검증을 수행하는 리졸버는 DNS 레코드 대신 SERVFAIL 오류를 반환합니다. KSK 롤오버 이후 새 DS 레코드를 상위 존에 제출하지 않았거나, 상위 존이 아직 제출한 업데이트를 게시하지 않은 경우에 흔히 발생합니다.

ZSK와 KSK가 모두 필요한가요? 하나의 키로는 안 되나요?

가능합니다 — 일부 운영자는 두 역할을 모두 수행하는 CSK(Combined Signing Key)를 사용합니다. 하지만 두 키 방식이 존재하는 이유는, KSK를 변경하면 상위 존의 DS 레코드 업데이트가 필요하기 때문입니다. 시간과 조율이 필요한 작업이죠. 키를 분리하면 상위 존에 손대지 않고도 ZSK를 자주 교체할 수 있습니다.

리졸버는 루트 존의 공개 키를 어떻게 얻나요?

루트 키(신뢰 앵커)는 DNS 리졸버 소프트웨어에 내장되어 배포되며, IANA의 공식 게시를 통해서도 제공됩니다. 또한 RFC 5011의 자동화된 신뢰 앵커 업데이트를 통해 갱신됩니다. 이 방식은 리졸버가 보류 기간 동안 일관되게 서명된 것을 관찰함으로써 새 키를 안전하게 습득할 수 있게 해줍니다. 루트 키는 DNSSEC 자체로는 검증할 수 없는 유일한 키입니다 — 다른 수단을 통해 신뢰해야 합니다.

DS 다이제스트 유형 1, 2, 4의 차이는 무엇인가요?

다이제스트 유형 1은 SHA-1입니다(폐지됨, 사용 금지). 다이제스트 유형 2는 SHA-256입니다(현재 표준). 다이제스트 유형 4는 SHA-384입니다(더 강력하지만 덜 일반적). DS 레코드를 만들 때는 최소한 SHA-256을 사용하세요. 많은 운영자들은 심층 방어를 위해 SHA-256과 SHA-384 DS 레코드를 모두 게시합니다.

키 롤오버 중 각 단계 사이에 얼마나 기다려야 하나요?

존의 최대 TTL 이상, 그리고 일반적으로 리졸버마다 캐싱 시간이 다를 수 있으므로 그보다 더 여유를 두어야 합니다. 많은 운영자들은 안전을 위해 TTL의 두 배를 기다립니다. 상위 존 업데이트가 포함된 KSK 롤오버의 경우, 전 세계적인 전파를 위해 며칠을 기다려야 할 수도 있습니다.

출처

पिछला

TXT 레코드: SPF, DKIM, 그리고 도메인 인증

क्या यह पृष्ठ सहायक था?

😔

🤨

😃