요약
draft-ietf-dnsop-dry-run-dnssec-01은 의도적으로 중간 상태를 제안한다. 지원 리졸버는 서명된 존을 검증하고 결함을 보고하지만, dry-run 검증이 bogus일 경우 일반 클라이언트에는 비보안 답변으로 폴백한다.- 제안된 NOERROR 보고는 참여 리졸버 하나가 성공적인 검사를 관찰했음을 증명할 뿐이다. 침묵하는 리졸버 모집단의 규모나 구성은 드러내지 않으며, RFC 9567 보고는 감쇠되고 인증되지 않는다.
- 부모가 dry-run DS를 실제 DS로 교체하기 전에, 운영자는 관찰된 코호트, 테스트 범위, 보고 한계, 부모 상태와 잔여 불확실성을 기록한 졸업 수취증이 필요하다. 이는 Daniel Kade의 거버넌스 권고이며 IETF 문서가 아니다.
DNSSEC 도입에는 무자비한 마지막 단계가 있다. 부모가 DS 레코드를 공개하기 전에는 서명된 자식 존을 신뢰 사슬을 만들지 않고 검사할 수 있다. 실제 DS가 보이는 이후에는 검증 리졸버가 서명 실수를 SERVFAIL로 만들 수 있다. 설정 변경은 작다. 그러나 서비스 결과는 존 운영자가 통제하지 않는 부모, 리졸버, 캐시, 클라이언트에 분산된다.
dry-run DNSSEC이라 불리는 활성 DNSOP 드래프트는 유용한 중간 지점을 만들려 한다. 2026년 6월 21일에 공개된 개정판 01은 워킹 그룹 인터넷 드래프트로, 본문은 Standards Track으로 표기한다. 이는 RFC도, 승인된 표준도, 배포의 증거도 아니다. 제안된 코드 포인트는 아직 완성되지 않았다.
이 방법은 RFC 6840이 미지 DS 다이제스트 알고리즘에 부여하는 동작을 이용한다. 검증기는 자신이 사용할 수 없는 다이제스트 알고리즘의 인증된 DS 레코드를 무시한다. 지원되는 인증 경로가 더 이상 없으면 자식을 서명되지 않은 것처럼 취급한다. 이 드래프트는 각 일반 다이제스트 알고리즘에 대해 상위 비트 대응값을 예약할 것을 제안한다. 부모는 자식에 대해 그 dry-run DS 값만 공개한다.
그러면 두 리졸버 모집단이 서로 다른 것을 본다. 이 제안을 모르는 리졸버는 낯선 다이제스트를 무시하고 자식을 비보안으로 처리한다. 지원 리졸버는 신호를 인식하고 자식을 검증하며 발견한 결과를 보고할 수 있다. 검증이 성공하면 인증 데이터를 반환할 수 있다. 검증이 bogus이면 일반 클라이언트에게 통상의 DNSSEC 실패를 숨기고, dry-run DS가 없었을 때와 같은 비보안 답변을 반환한다.
이는 부분적 DNSSEC 보호가 아니다. 드래프트는 dry-run 위임은 DNSSEC 서명된 것으로 간주되어서는 안 된다고 명시한다. 보안 절은 더 날카롭다. 비보안으로 폴백하면 데이터 무결성 보장이 비활성화되어 위조된 답변이 존에 영향을 줄 수 있다. 이 노출은 일반 해석을 망가뜨리지 않으면서 프로덕션 경로를 테스트하는 대가이다. 그래서 dry-run은 부모에 무기한 남겨진 안심 레이블이 아니라 중간 상태로 유지되어야 한다.
실패는 강제 없이도 보일 수 있다
테스트는 관찰과 결과를 분리한다. 지원 리졸버가 검증 작업을 수행한다. RFC 8914로 정의된 Extended DNS Errors가 결함의 종류를 식별한다. RFC 9567에서 표준화된 DNS Error Reporting은 권위 서버가 광고한 모니터링 에이전트 도메인 쪽으로 오류를 전달한다.
보고 질의는 결함이 있는 이름, 질의 유형, EDE 코드를 DNS 레이블로 인코딩한다. 이는 실제 검증 경로가 문제를 만났다는 증거를 존 운영자에게 준다. 배포된 리졸버, 실제 캐시, 일반 질의 패턴을 포함하므로 실험실 검사보다 가치 있다.
또한 유한한 신호이기도 하다. RFC 9567은 보고 리졸버를 모니터링 에이전트에 인증하지 않는다. TCP나 DNS Cookies는 출처 주소 위조를 어렵게 만들지만, 겉보기 출처는 제도적 정체성이 아니다. UDP로 전송된 보고는 거짓일 수 있다. 오류 보고는 오래된 신뢰 앵커를 포함한 리졸버의 로컬 실수를 드러낼 수 있으며, RFC는 프라이버시를 위해 질의 이름 최소화를 권고한다.
캐싱은 의도적으로 트래픽을 줄인다. 리졸버가 모니터링 에이전트에 접속한 뒤에는 이후 보고가 감쇠될 수 있다. 구성된 QNAME이 DNS 한도를 초과하면 보고는 전송되지 않는다. 따라서 모니터링 대시보드는 모든 실패 질의의 원시 집계가 아니라 형태가 다듬어진 표본을 기록한다.
이런 조건들이 보고를 무용하게 하지는 않는다. 보고가 무엇을 증명하는지를 정의할 뿐이다. 하나의 보고는 어떤 보고 경로가 어떤 시점에 명명된 오류를 관찰했다는 사실을 확립할 수 있다. 그것만으로 몇 명의 최종 사용자가 영향을 받았는지, 성공 질의가 얼마나 있었는지, 출처가 서로 다른 리졸버 모집단을 대표하는지는 확립할 수 없다.
침묵에는 양성 신호가 필요했다
dry-run은 익숙한 측정 함정을 만든다. 비어 있는 오류 로그는 서명된 존이 정확하다는 뜻일 수 있다. 그러나 지원 리졸버가 질의하지 않았거나, 보고가 감쇠되었거나, 모니터링 에이전트에 도달할 수 없었거나, QNAME이 너무 길었거나, 리졸버가 보고를 구현하지 않았다는 뜻일 수도 있다.
개정판 01은 이 모호성의 한 부분을 제안된 NOERROR Extended DNS Error 코드로 다룬다. 지원 리졸버가 dry-run 존을 성공적으로 검증하면 양성 보고를 보낼 수 있다. 질의 이름에 존 아펙스를 사용해 모니터링 에이전트가 존을 구분하면서 신호를 해당 존 수준의 존재 확인으로 한정한다. 동일한 캐싱 기계가 반복되는 NOERROR 보고를 감쇠한다.
이는 조용한 그래프의 의미를 바꾼다. 성공 보고는 한 참여자가 존재했음을 증명한다. NOERROR와 오류 보고의 조합은 관찰된 코호트 내부의 결과를 기술할 수 있다. 그러나 이 기계에는 여전히 외부 분모가 없다. 미지원 리졸버는 낯선 다이제스트 알고리즘을 서명되지 않은 위임으로 취급하므로 설계상 침묵한다. 질의를 받지 못한 지원 리졸버도 침묵한다. 리졸버의 단일 양성 보고는 그 뒤의 모든 클라이언트나 이후의 모든 캐시 상태를 열거하지 않는다.
드래프트 자체는 DMARC 보고, RFC 8509의 루트 키 센티넬, RFC 8145의 신뢰 앵커 시그널링을 가리킨다. 그 교훈은 작은 표본이 보편적이 된다는 것이 아니다. 최신이고 전략적으로 배치된 관찰자 집합이 상당한 운영 증거를 제공할 수 있다는 것이다. 거버넌스상의 실수는 "집합"이라는 단어를 지우는 것이다.
웨트런은 실패를 수용하는 주체를 바꾼다
제안된 dry-run 모드에서 일반 클라이언트는 폴백 열림(fail-open) 답변을 받는다. 이는 서비스 안전한 관찰을 가능하게 하지만, DNSSEC 강제가 실제로 응답을 거부할 때 애플리케이션이 어떻게 동작하는지는 검사하지 않는다.
그래서 드래프트는 Wet-Run EDNS 옵션을 제안한다. 클라이언트는 지원 리졸버에 실제 dry-run 검증 오류를 노출해 달라고 명시적으로 요청할 수 있다. 리졸버는 통상의 캐시된 상태 옆에 dry-run 상태를 유지하고, 실패를 반환할 때 이 옵션을 되돌려 주어야 한다. 옵션을 이해하지 못하는 리졸버는 이를 무시한다.
이는 별개의 동의·범위 표면이다. Wet-Run 프로브는 선택된 클라이언트, 네트워크, 리졸버 경로가 기대한 실패 의미를 받는다는 것을 보여줄 수 있다. 옵트인하지 않은 클라이언트에 대해서는 아무것도 말하지 않는다. 리졸버 측 NOERROR 보고와 클라이언트 측 Wet-Run 결과는 서로 다른 질문에 답한다. 둘을 "테스트 통과"로 합치면 테스트된 경로의 정체성이 사라진다.
부정 답변에는 또 다른 프로브가 필요하다. RFC 8198은 검증기가 캐시된 NSEC 또는 NSEC3 증명에서 답변을 합성할 수 있게 한다. 이 효율성은 리허설 동안 결함이 있는 부정 증명을 숨길 수 있다. 리졸버가 권위 서버에 접속하지 않고 답변할 수 있기 때문이다. 개정판 01은 dry-run 리졸버에 그 합성을 일시 중지하고, 명시적 질의를 발행하고, 답변을 비교하고, 불일치를 제안된 오류 코드로 보고하도록 지시한다. 따라서 준비 상태는 성공적인 양성 조회만으로 판단할 수 없다.
부모가 졸업 스위치를 쥐고 있다
dry-run은 자식 서명자만으로 설치되지 않는다. 부모가 특수 DS 상태를 공개해야 한다. 부모가 DS 레코드를 수용하면 자식이 dry-run DS를 제공한다. 부모가 보통 DNSKEY로부터 DS를 생성한다면, 함께 제공된 CDS를 검사하는 인터페이스 플래그나 로직이 필요하다. CDNSKEY만으로는 제안된 dry-run 구분을 운반할 수 없으며, 드래프트는 자식에 CDS와 CDNSKEY를 모두 공개하도록 권고한다.
졸업 역시 부모의 동작이다. 드래프트는 턴키 커밋먼트를 dry-run DS를 실제 DS RRset으로 교체하는 것으로 기술한다. 이 표현은 운영적으로 우아하지만 증거적으로 밀도가 높다. 제출된 변경은 수용된 변경이 아니며, 수용은 공개가 아니고, 관찰된 한 번의 부모 응답은 보편적인 캐시 만료가 아니다.
교체는 리졸버와의 계약도 바꾼다. 리허설 동안 지원 리졸버는 bogus 상태를 보고하면서도 일반 클라이언트에게 비보안 답변을 줄 수 있다. 실제로 지원되는 DS 아래에서는 같은 결함이 검증 실패가 된다. 따라서 대시보드 임계값은 단순한 모니터링 선호가 아니다. 외부 모집단이 언제 자식 존의 주장을 강제하기 시작할지 승인하는 데 도움을 준다.
신호에는 여전히 레지스트리 자리가 필요하다
개정판 01은 DS 다이제스트 알고리즘 값의 최상위 비트를 사용하고, IANA에 128부터 255까지를 Dry-run DNSSEC으로 식별해 줄 것을 요청한다. 현재 IANA 다이제스트 알고리즘 레지스트리에는 그 할당이 없다. 2026년 1월 13일에 갱신된 이 레지스트리는 128–252를 Reserved, 253–254를 Private Use, 255를 Unassigned로 표기하며 RFC 9904를 참조로 둔다.
이는 거부나 불가능성의 증거가 아니라 현재 상태의 불일치이다. 인터넷 드래프트에는 작업이 진전될 때에만 발생하는 제안된 IANA 조치가 흔히 담긴다. 행과 권고 열은 명시적으로 조정되어야 한다. 그 전까지 실험은 드래프트가 요청한 블록을 공개 할당으로 취급할 수 없다.
RFC 9904는 두 번째 유용한 구분을 추가한다. 레지스트리는 이제 구현 권고와 별도로 사용 권고를 기록한다. 소프트웨어 역량과 운영자 배포는 같은 사실이 아니다. dry-run 증거도 같은 구조를 지닌다. 리졸버는 이 존을 관찰하지 않고도 기능을 구현할 수 있다. 존은 부모가 지원하지 않는 데도 기능을 요청할 수 있다. 부모는 대표 클라이언트가 지원 리졸버를 거쳐 간다는 증명 없이 신호를 공개할 수 있다.
졸업 수취증
신뢰할 수 있는 졸업 기록은 정확한 아티팩트로 시작해야 한다. 서명된 존의 지문, DNSKEY 집합, 제안된 dry-run DS 집합, 부모 제출, 관찰된 부모 공개가 그것이다. 수용과 가시성을 구분하기 위해 사용된 관찰 창과 권위 관찰 지점을 명명해야 한다.
수취증은 인구조사를 암시하는 대신 코호트를 기술해야 한다. 어떤 보고 리졸버가 독립적으로 식별 가능했는가? 어떤 것이 TCP 또는 Cookie 신뢰도만 지닌 출처 주소였는가? 감쇠를 거친 후 몇 개의 NOERROR와 오류 신호가 남았는가? 어떤 오류 코드가 어떤 이름과 질의 유형에서 나타났고, 어떤 수정이 이어졌는가? 집계는 결정에 필요한 증거를 보존하면서 프라이버시를 유지할 수 있다.
클라이언트 테스트는 자체 절에 있어야 한다. 네트워크, 리졸버, 애플리케이션 클래스별 Wet-Run 프로브, 통상 폴백, 양성과 부정 답변, NSEC/NSEC3 명시 질의 검사, 캐시 수평선, 그리고 테스트가 닿지 못한 사례들이다. 현재 IANA 레지스트리 스냅샷과 구현된 실험 코드 포인트는 할당된 것처럼 제시하지 않고 기록해야 한다.
마지막으로 수취증은 누가 실제 DS를 승인할 수 있는지, 최소한의 어떤 증거를 수용했는지, 어떤 잔여 불확실성이 남았는지, 롤백을 누가 책임지는지 명명해야 한다. 실제 제출, 부모 수용, 관찰된 공개, 변경 후 검증은 별도의 타임스탬프여야 한다.
어떤 수취증도 모든 리졸버를 증명할 수 없다. 그 목적은 선택된 표본이 결정 기록에서 조용히 "인터넷"으로 굳어지는 것을 막는 것이다. 유한한 주장도 조치를 지탱할 수 있다. 다만 그 불확실성을 결과를 감당할 사람들이 검토할 수 있게 만들 뿐이다.
출처
- dry-run DNSSEC — 개정판 01
- dry-run DNSSEC Datatracker 기록
- dry-run DNSSEC 문서 이력
- DNSOP 활성 문서
- DNSOP 헌장
- RFC 9567 — DNS Error Reporting
- RFC 8914 — Extended DNS Errors
- RFC 6840 — DNSSEC Implementation Notes
- RFC 8198 — Aggressive Use of DNSSEC-Validated Cache
- RFC 8509 — Root Key Trust Anchor Sentinel
- RFC 8145 — Signaling Trust Anchor Knowledge
- RFC 9904 — DNSSEC Cryptographic Algorithm Recommendation Update Process
- IANA DS 다이제스트 알고리즘 레지스트리
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





