DNSSEC 서명 축소 제안과 검증기의 로컬 정책 책임

Summary

IETF DNSOP의 첫 작업반 초안은 DS 또는 신뢰 앵커 집합에 UNIVERSAL 알고리즘이 있고 FORMERLY-UNIVERSAL이 없을 때, 그중 하나로만 서명해도 되도록 제안한다.
알고리즘 8과 13이 처음 UNIVERSAL로 지정될 예정이다. 현재 IANA 등록부는 둘 모두를 검증 구현 필수로 표시하지만, 새 상태 열은 아직 없다.
검증기가 광고된 UNIVERSAL 알고리즘을 로컬 정책으로 끄면, 다른 광고 알고리즘을 지원하더라도 영역을 서명되지 않은 것으로 분류한다. 운영자의 설정이 인증 결과를 바꾼다.

DNS 영역은 두 알고리즘을 광고하면 두 알고리즘의 서명을 만들어야 한다. 검증기는 그중 유효한 경로 하나를 받아들이면 된다. RFC 4035와 RFC 6840의 조합은 모르는 검증기까지 고려한 호환성 보험이다. 보험료는 매번 서명하는 쪽이 낸다. 새 초안은 모든 검증기가 사용할 것으로 기대되는 알고리즘이 있다면 이 비용을 줄이자고 한다.

두 DNS 사업자가 한 영역을 독립된 키로 서명할 때 차이가 커진다. RFC 8901의 다중 서명 모델에서 사업자마다 알고리즘이 다르면, 기존 전부 서명 규칙은 서로의 작업을 맞추도록 강요한다. 사업자를 교체하는 동안에도 비슷한 병목이 생긴다. 새 신뢰 앵커를 미리 배포하고 싶은데 그와 연결된 서명을 당장 영역 전체에 뿌려야 한다면, 준비와 전환을 분리할 수 없다.

UNIVERSAL이라는 이름의 계약서

초안은 IANA DNSSEC 알고리즘 표에 Validation support status 열을 추가하려 한다. 값은 UNIVERSAL, FORMERLY-UNIVERSAL, 공란이다. 처음에는 번호 8의 RSA/SHA-256과 번호 13의 ECDSA P-256/SHA-256이 UNIVERSAL로 지정된다. 현재 표도 두 알고리즘의 검증 구현을 필수로 정한다. 과거에는 보편적이었지만 지원이 줄어든 알고리즘을 위한 FORMERLY-UNIVERSAL에는 초기 항목이 없다.

새 서명 규칙은 상위 영역의 DS나 신뢰 앵커 집합을 본다. UNIVERSAL이 하나 이상이고 FORMERLY-UNIVERSAL이 없으면, UNIVERSAL 하나의 서명은 필수이고 나머지는 선택이다. DNSKEY도 실제 서명에 사용한 알고리즘의 것만 둘 수 있다. UNIVERSAL이 없거나 과거 UNIVERSAL이 하나라도 있으면 모든 알고리즘으로 서명해야 한다. 키를 여러 개 적어 두었다는 이유만으로 마음대로 서명을 생략할 수 있다는 얘기가 아니다.

이 조건에서는 8을 쓰는 사업자와 13을 쓰는 사업자가 각각 유효한 응답을 낼 수 있다. 새 신뢰 앵커를 대응하는 DNSKEY와 RRSIG보다 먼저 공개하는 길도 생긴다. 한 사업자가 실험적인 양자내성 알고리즘을 시험할 때 모든 협력 사업자에게 같은 날 도입을 요구할 필요도 줄어든다. 다만 새 알고리즘이 UNIVERSAL이 아니라면 전환 완료에는 이중 서명 기간이 필요할 수 있다.

로컬 차단을 영역의 잘못으로 돌리지 말라

영역이 8과 13을 광고하고, 한 사업자가 8로 유효한 경로를 제공한다고 하자. 검증기 운영자는 8을 자체 설정으로 껐지만 13은 여전히 지원한다. 초안은 그 검증기가 영역을 서명되지 않은 상태로 취급하도록 한다. 자신이 필수 지원 알고리즘을 끈 결과를 영역의 잘못된 서명인 bogus로 판정하고 SERVFAIL을 돌려줄 수 없다는 뜻이다. 과거 UNIVERSAL이었던 알고리즘에도 같은 책임 원칙이 적용된다.

DNS 질의가 성공했다는 사실은 이 검증기에서 DNSSEC 인증이 수행되었다는 증거가 아니다. secure, insecure, bogus를 구분해 기록해야 한다. 특히 알고리즘을 끈 담당자와 시점을 남겨야 한다. 기술적으로 유효한 서명 경로와 조직이 그것을 검증하기로 한 결정은 서로 다른 기록이다.

기존의 전부 서명 규칙에는 공격을 막는 이유도 있었다. 공격자가 검증기가 이해할 수 있는 서명을 지워, 원래 안전했던 응답을 조용히 비보안 상태로 떨어뜨리면 안 된다. 초안은 UNIVERSAL과 FORMERLY-UNIVERSAL이라는 이력을 검증기가 기억하게 하여 이런 강등을 막겠다고 설계한다. 이 이력을 구현하지 못한 검증기는 결과를 잘못 분류할 수 있다.

문서는 2026년 10월 31일 자 작업반 초판이다. 실제로 영향을 받는 검증기 수나 장애 발생량은 제시하지 않는다. 운영 결정을 바꿀 수 있는 사실은 자체 시험 결과다. 사업자별 서명 일부만 받은 경우와, 번호 8이나 13을 일부러 끈 경우에 검증기마다 어떤 상태가 나오는가. 제품 설명서의 “DNSSEC 지원” 한 줄로는 이 조합을 보증할 수 없다.

초안이 주는 자유는 서명자에게만 있는 것이 아니다. 검증기 운영자는 자기 알고리즘 정책을 정할 자유가 있다. 그 선택 때문에 인증을 포기했다면, 성공한 DNS 응답 뒤에 숨기지 말고 결과에 드러내야 한다.

IETF 초안 · RFC 4035 · RFC 6840 · RFC 8901 · IANA 등록부