자기 서명 DNS 업데이트는 권한을 증명하지 않는다

요약

draft-ietf-dnsop-delegation-mgmt-via-ddns-02는 자식 존이 정확한 NS, 글루 또는 DS 변경을 DNS UPDATE를 통해 부모 측 UPDATE Receiver에 전송하고, SIG(0)로 인증하며, DSYNC를 통해 수신자를 찾도록 제안한다.
부트스트랩 요청은 자기 서명이다. 이는 제시된 개인 키의 보유를 증명할 뿐, 자식 존을 관리할 권한을 증명하지 않는다. 수신자는 승인된 검증 방법이 키를trusted로 승격할 때까지 해당 키를known상태로만 유지해야 한다.
지속적인 권한 전환 영수증은 기존 키, 제안된 키, 부트스트랩 방법, 독립적 증거, 정책 판정, 승인된 업데이트, 관측된 부모 게시를 함께 묶어야 한다. 이는 거버넌스 권고이며 DNSOP 요구사항이 아니다.

부모가 정돈된 요청을 받는다고 상상해 보자. 기존 KEY 세트를 삭제하고, 이 새로운 공개 키를 추가하고, 그 동일한 새 키의 개인 키 부분으로 메시지를 검증하라는 요청이다. 서명 검증은 통과한다. 전송 중에 손상된 것은 없다. 발신자가 부모가 신뢰하기를 원하는 키를 보유하고 있다는 점은 부인할 수 없다.

그것은 이 교환에서 가장 놀랍지 않은 사실이기도 하다. 누구나 키 쌍을 생성하고 그것으로 요청에 서명할 수 있다. 제도적 질문은 암호학이 끝나는 지점에서 시작된다. 왜 이 특정 키가 이제child.parent.의 위임을 지배해야 하는가?

Automating DNS Delegation Management via DDNS의 리비전 02는 2026년 6월 17일에 게시되었다. 이는 활동 중인 DNSOP 워킹그룹 인터넷 드래프트이며, 여전히 작업 중으로 변경되거나 만료될 수 있다. 렌더링된 문서는 의도된 상태를 Standards Track으로 표기하지만, Datatracker 요약에서는 해당 필드가 비어 있다. 이는 RFC가 아니며, 이 문서의 게시로부터 어떤 배포도 추론해서는 안 된다.

이 드래프트는 실제 운영상의 실패를 다룬다. 자식 존이 권한 서버나 DNSSEC 자료를 변경했는데 부모가 이전 NS, 글루 또는 DS 레코드를 유지하는 경우가 있다. 자식은 이전 구성의 일부를 통해 계속 응답할 수 있어, 또 다른 장애가 남은 경로를 제거하기 전까지는 불일치가 견딜 만한 것처럼 보인다. 여유 용량처럼 보였던 것은 이미 사라진 뒤였다.

기존 CDS 및 CSYNC 스캐너를 사용하면 부모가 자식 존을 폴링하여 일부 요청된 변경을 발견할 수 있다. 드래프트의 대안은 자식이 위임 데이터가 변경될 때 일반적인 보안 DNS UPDATE를 푸시하도록 한다. DSYNC 레코드는 부모가 이 목적의 UPDATE를 수용하는지 알려주고 수신자와 포트를 식별한다. 이 제안은 스캔 지연을 없앨 수 있고, 서명된 자식뿐 아니라 서명되지 않은 자식도 지원할 수 있다.

그 효율성 향상은 거버넌스 문제를 옮길 뿐, 해소하지는 않는다.

패킷은 변경을 담을 뿐, 위임장을 담지 않는다

DNS UPDATE는 한 가지 좁은 측면에서 알림보다 강력하다. 알림은 수신자가 변경을 찾아봐야 한다고 암시한다. UPDATE는 발신자가 적용되기를 원하는 추가와 삭제를 담고 있다. SIG(0)는 트랜잭션을 개인 키에 결속하고, 수신자가 이미 신뢰하는 공개 키를 기준으로 무결성과 출처를 검증할 수 있게 한다.

드래프트는 마지막 문구에 신중하다. SIG(0) 서명은 DNSSEC 서명만큼 강력한 암호학을 사용할 수 있지만, 신뢰 모델은 다르다. DNSSEC 검증은 일반적으로 구성된 신뢰 앵커까지 서명을 따라간다. 제안된 UPDATE 키는 부트스트랩 절차 이후 개별적으로 신뢰된다. 수학적 강도는 초기 권한에 관한 빠진 결정을 대체할 수 없다.

따라서 UPDATE Receiver는 운영 중인 부모 존에 대한 서명 제어식 쓰기 소켓이 되도록 의도된 것이 아니다. 이는 별도의 부모 서비스일 수도 있고, 레지스트라와 같은 제3자일 수도 있다. 이것은 변경을 의도된 NS, 글루, DS 및 키 관리 범위로 제한하고, CDS 또는 CSYNC 처리에 사용되는 정확성 검사를 적용하고, 감사 추적을 보존하고, 승인된 변경을 부모의 프로비저닝 시스템에 넘겨야 한다.

일반적인 권한 부여 규칙은 키 이름에도 범위를 부여한다.child.parent.에 대한 업데이트는 정확히 그 이름을 가진 신뢰된 SIG(0) 키로 서명되어야 한다. 이는 한 자식의 키가 다른 자식의 위임을 다시 쓰는 것을 막는다. 수신자는 여러 자식에 대해 권한을 부여받은 레지스트라 키 같은 대안 방식을 사용할 수 있지만, 그 경우 수신자는 각 자식 수준의 변경을 다른 수단으로 권한 부여할 책임을 진다.

이름 범위는 신뢰된 키가 어떤 객체를 건드릴 수 있는지에 답한다. 키가 어떻게 신뢰되게 되었는지에는 답하지 않는다.

`known`은 의도적으로`trusted`보다 약하다

최초 부트스트랩 요청은 자기 서명이다. 이는 KEY 레코드를 제안하며, 즉시 실행될 경우 기존 키 세트를 삭제하게 되는 지시를 담을 수도 있다. 수신자는 자기 서명을 검증하고 제시된 키를known으로 표시할 수 있다.

거기서 멈춰야 한다. 드래프트에 따르면 자기 서명은 발신자가 해당 개인 키를 보유하고 있음만을 증명한다. 발신자가 자식의 위임을 관리할 권한이 있음을 증명하지는 않는다. 키는 별도의 검증 단계가 성공한 뒤에만trusted가 된다. 그때까지 이전에 신뢰된 키는 제거되어서는 안 된다.

이것은 방어적 프로그래밍 그 이상이다. 이는 기계 권한을 위한 2단계 구성이다. 자격 증명을 아는 것은 관측이다. 자격 증명에 권한을 맡기는 것은 결정이다. 구현이 두 상태를 하나의 불리언으로 저장하거나 대시보드가 둘 다 “키 존재”로 표시한다면, 프로토콜 문구가 그 구분을 보존하는 동안에도 구분은 사라질 수 있다.

기존 키에 관한 규칙은 그 구분에 실질적 힘을 부여한다. 공격자는 언제든 새로운 자기 서명 키를 제출할 수 있다. 그 메시지가 검증 전에 기존 신뢰 키를 축출할 수 있다면, 실패한 부트스트랩만으로도 이미 피해가 발생했을 것이다. 성공적 승격까지 현직 키를 유지하면, 권한 없는 요청이 서비스 거부 명령이 아니라 무해한 증거로 바뀐다.

부트스트랩 방법은 서로 다른 주체를 주장한다

이 제안은 known에서 trusted로 가는 경로를 하나 이상 제공하는데, DNS 배포 환경이 하나의 서명 상태를 공유하지 않기 때문이다.

DNSSEC으로 서명된 자식의 경우, 공개 SIG(0) 키를 자식 에이펙스에 게시하고 기존 체인을 통해 검증할 수 있다. 권한 네임서버가 서명된 존에 있는 서명되지 않은 자식의 경우, 자식의 키를 그 네임서버 아래의 특별한 이름으로 재게시하고 그곳에서 검증할 수 있다. 두 번째 경로는 네임서버 운영자의 협력을 필요로 한다. 드래프트는 별도의 의도 신호를 권장하지만 공급자의 프로비저닝 인계는 범위 밖으로 남겨 둔다.

완전히 서명되지 않은 자식의 경우, 제안된 정책은 RFC 8078의 계보를 따른다. 여러 네트워크 관측 지점에서, 여러 시점에, 가능한 경우 더 강력한 전송 수단을 통해 키를 반복적으로 가져오고, 일관된 관측만 수용한다. 이는 일시적인 경로상 대체의 비용을 높인다. 서빙 인프라에 대한 관측을 등록자의 신원 증명으로 바꾸지는 않는다. 드래프트는 이 방법이 등록자가 아니라 권한 서버의 현재 운영자를 인증하며, 자동 방법 중 가장 약하다고 밝힌다.

수동 부트스트랩도 여전히 사용할 수 있다. 이는 기존 포털, 인증된 지원 교환, 또는 다른 대역 외 절차를 포함할 수 있다. “수동”이 자동으로 더 강하거나 더 약한 것은 아니다. 그 보증 수준은 누가, 어떤 권한 기록에 대조되어, 어떤 복구 경로를 통해 확인되는지, 그리고 어떤 증거가 보존되는지에 달려 있다.

이 방법들은 하나의 추상적 증명을 서로 교체 가능한 방식으로 구현한 것이 아니다. 서로 다른 주체에 관한 서로 다른 질문에 답한다. DNSSEC 체인은 키를 서명된 자식 네임스페이스에 결속할 수 있다. 다중 지점 관측은 현재 권한 응답에 대한 지속적 통제를 보여줄 수 있다. 레지스트라의 인증된 프로세스는 요청자를 계정 또는 등록자 기록에 결속할 수 있다. 부모는 그 권한을 대표할 증거를 선택하기 전에 어떤 주체에게 권한을 부여하려는지 명시해야 한다.

기능 탐색 자체가 신뢰 경로를 바꿀 수 있다

부모는 DSYNC 대상의 SVCB 레코드에 있는bootstrap매개변수를 통해 지원되는 부트스트랩 방법을 알릴 수 있다. 그러면 자식은 수신자가 에이펙스 검증, 네임서버 보조 검증, 서명 없는 다중 지점 수용, 수동 처리를 지원하는지 확인할 수 있다.

이는 유용한 상호운용성 데이터이지만, 결정에 참여한다. 공격자가 서명되지 않은 광고를 위조할 수 있다면, 더 강한 방법에서 더 약한 서명 없는 경로로 자식을 유도할 수 있다. 따라서 드래프트는 부모가 DNSSEC을 지원하는 경우 해당 SVCB 레코드에 서명하고, 자식이 충족할 수 있는 가장 강한 광고 방법을 선택할 것을 권장한다.

따라서 운영자는 최종적으로 사용된 방법만 기록해서는 안 된다. 광고된 방법 집합, 광고가 검증되었는지 여부, 자식이 사용할 수 있는 방법, 선택 규칙을 보존해야 한다. 그렇지 않으면 나중의 검토자는 성공한 부트스트랩은 볼 수 있지만 그 전에 다운그레이드가 있었는지는 알 수 없다.

수용은 게시가 아니다

신뢰된 키가 범위 내 UPDATE에 서명하더라도, 수신자는 여전히 로컬 정책과 정확성 검사를 적용한다.NOERROR응답은 요청이 수신되고 수용되었으며, 변경이 나중에 부모 존에 나타날 것이라는 뜻이다. 게시가 이미 이루어졌다는 뜻은 아니다.

이 시간적 경계는 네임서버 이전과 DNSSEC 롤오버에서 중요하다. 수용을 가시적 상태로 간주하는 자식은 이전 서비스를 너무 일찍 철회할 수 있다.NOERROR에서 티켓을 닫는 모니터링 시스템은 리졸버가 여전히 이전 위임을 보는 동안에도 수렴되었다고 보고할 수 있다. 부모 존의 최종 상태만 저장하는 감사는 나중에 어떤 수용된 명령이 그 상태를 만들었는지 판별할 수 없다.

네 가지 상태는 구분되어야 한다. 수신자가 키를 아는 상태, 수신자가 키를 신뢰하는 상태, 수신자가 서명된 업데이트를 수용하는 상태, 부모가 그 결과 위임을 게시하는 상태다. 실패와 복구는 각 경계마다 다르다.BADKEY는 수신자가 키를 알지 못한다는 뜻일 수 있다. 키는 알려져 있으나 여전히 검증을 기다리는 상태일 수 있고, 검증에 실패했을 수도 있다. 유효하고 신뢰된 업데이트라도 정책에 의해 거부될 수 있다. 수용된 업데이트는 프로비저닝에서 대기할 수 있다. 게시된 변경은 나중에 롤백될 수 있다.

상호 인증은 또 다른 비대칭을 추가한다. 부모는 변경을 수용하기 전에 자식 키를 신뢰해야 한다. 자식은 키 상태 응답에 안전하게 대응하기 전에 수신자의 응답 키를 신뢰해야 한다. 부모가 서명되지 않았고 수동 수신자 키 부트스트랩이 없었던 경우, 위조된 응답은 위임 변경을 승인할 수는 없지만 혼란을 유발하거나 불필요한 재부트스트랩을 촉발할 수 있다. “요청이 안전했다”와 “응답을 신뢰할 수 있었다”는 별개의 진술이다.

권한 전환을 보존하라

나는 모든 부트스트랩과 재부트스트랩에 대해 권한 전환 영수증을 제안한다. 이는 자식 비밀의 공개 레지스트리가 아니며, 드래프트가 요구하는 필드 집합도 아니다. 이는 효율적인 프로토콜이 가장 중요한 결정을 설명 없는trusted=true로 압축해 버리지 않도록 하는 접근 통제된 기록이다.

영수증은 부모, 자식, DSYNC 응답과 검증 상태, UPDATE Receiver 신원, 소프트웨어 및 정책 버전, 기존 신뢰 키 지문, 제안된 키 지문, 서명 시각, 정확한 부트스트랩 요청 다이제스트로 시작한다. 어떤 부트스트랩 방법이 광고되었고, 어떤 방법이 사용 가능했으며, 무엇이 선택되었고 그 이유가 무엇인지 기록한다.

증거 섹션은 권한이 부여되는 주체를 기록한다. 에이펙스 또는 네임서버 보조 검증의 경우 DNSSEC 체인 결과, 관측 시각, 사용된 이름을 보관한다. 서명 없는 부트스트랩의 경우 관측 지점 독립성, 시각, 전송 수단, 전체 응답 지문, 일관성 판정을 기록한다. 수동 부트스트랩의 경우 인증된 세션, 확인된 계정 또는 등록자 권한, 검토자 또는 자동 통제, 챌린지, 복구 예외, 승인 결과를 참조하되 민감한 개인 데이터는 게시하지 않는다.

결정 섹션은known, 검증 시작, 검증 실패, trusted, 대체됨, 폐기됨을 각각 시각 및 행위자와 함께 분리한다. 이는 대체 키가 검증될 때까지 현직 키가 활성 상태로 유지되었음을 증명한다. 이후의 업데이트 기록은 신뢰된 키, 정확한 NS/글루/DS 차이, 정확성 검사, 정책 판정, 응답, 프로비저닝 작업을 결속한다. 최종 관측은 의도된 부모 RRset이 실제로 언제 가시화되었고 어느 권한 서버에서 보였는지 기록한다.

이 영수증은 재부트스트랩을 거버넌스 가능하게 만든다. 자식 개인 키 분실, 부모가 저장한 공개 키 분실, 실패한 롤오버는 같은 사건이 아니다. 각각은 다른 청구자, 복구 권한, 폐기 위험을 가진다. “최초와 동일한 메커니즘”을 반복하는 것은 최초 메커니즘과 그 증거가 여전히 발견 가능할 때만 운영상 합리적이다.

이 드래프트의 가장 강력한 통찰은 서명이 위임 변경을 자동화할 수 있다는 것이 아니다. 그것은 오래전부터 기술적으로 가능했다. 핵심은 부모가 자기 서명에서 신뢰로 곧장 가는 유혹적인 지름길을 거부해야 한다는 점이다. 키는 스스로를 소개할 수 있다. 책임 있는 권한 프로세스만이 키에 힘을 부여할 수 있다.

자기 서명 위임 업데이트는 키를 증명할 뿐, 권한을 증명하지 않는다

왜 중요한가