요약

  • RFC 9718은 DNSSEC 루트 키 자료와 그 배포를 인증하는 메커니즘을 분리합니다. ICANN CA와 Web PKI는 파일 검증에 도움을 줄 수 있지만, 어느 쪽도 DNSSEC 트러스트 앵커가 아닙니다.
  • 사용 가능한 앵커는 다섯 가지 서로 다른 판단의 결과입니다. 진본 파일, 유효 시간 구간, 내부적으로 일관된 표현, 지원되는 파싱, 그리고 의도적인 로컬 수용.

신뢰 사슬은 위에서 아래로 설명하는 것이 가장 쉽습니다. 검증기는 신뢰된 키로 시작해 루트를 확인하고, 서명된 위임을 따라 내려갑니다. 그런데 어색한 질문은 위를 향합니다. 첫 번째 키를 누가 검증했는가?

RFC 4033은 이 경계를 감추지 않고 답합니다. 트러스트 앵커란 검증 리졸버에 설정된 DNSKEY 또는 DS 다이제스트이며, 그 초기 값은 DNS 외부의 안전하거나 신뢰된 경로를 통해 전달되어야 합니다. DNSSEC은 앵커 이후를 인증할 뿐, 앵커를 신뢰하게 만든 그 결정 자체를 인증하지는 않습니다.

이 구분이 바로 Joe Abley가 공동 집필하여 2025년 1월 IETF Informational RFC로 발표된RFC 9718의 지속적인 기여입니다. 이 문서는 RFC 7958을 폐기하고 IANA가 루트 존 트러스트 앵커 정보를 공개하는 방식을 규정합니다. 그 중요성은 대역 외 신뢰를 없앤 데 있지 않고, 그 주변의 이음새를 명확히 표시한 데 있습니다.

첫 번째 이음새는 객체와 그 봉투 사이에 있습니다. IANA는KeyDigest레코드를 담은 XML 문서를 공개합니다. 분리된 CMS 서명은 ICANN이 관리하는 인증 기관으로 연결될 수 있고, HTTPS는 Web PKI 아래에서 전송을 인증할 수 있습니다. 이 메커니즘들은 수신자가 문서가 기대한 발행자에게서 왔으며 손상되지 않았는지를 판단하는 데 도움을 줍니다.

그러나 RFC 9718은 운영 현장의 관용어가 지워버리는 사실을 밝힙니다. ICANN CA는 DNSSEC 트러스트 앵커가 아닙니다. 인증서 체인은 공개 객체를 인증할 뿐이며, 그 객체 안의 키 다이제스트 또는 공개 키 자료가 처리와 수용을 거친 뒤에야 DNSSEC 앵커가 될 수 있습니다. 둘을 다시 '신뢰의 루트'라고 부르면 서로 다른 두 시스템이 하나로 뭉개지고, 운영자가 상태를 전환한 지점이 가려집니다.

RFC 7958에서의 개정은 이 분리를 더 선명하게 만듭니다. 구버전의 공개 설계에는 키별 PKIX 인증서와 인증서 서명 요청이 포함되어 있었고, 분리된 OpenPGP 메커니즘도 기술하고 있었습니다. RFC 9718은 이 경로들을 제거했습니다. 그 설명은 보기 드물게 솔직합니다. 인증 키에 대한 대역 외 신뢰와 DNSSEC 루트 키에 대한 대역 외 신뢰가 섞여 있었다는 것입니다. 더 많은 암호 포장이 부트스트랩 결정을 없앤 것이 아니라, 그 결정을 이름 붙이기 더 어렵게 만든 것입니다.

XML 자체는 여러 독립적인 상태를 담고 있습니다.validFrom과validUntil은KeyDigest를 사용할 수 있는 구간을 기술합니다. 이는 모든 리졸버가 키를 설치했다는 예측도, 설치하라는 명령도 아닙니다. 처리기는 그 구간 밖의 항목을 사용해서는 안 됩니다. 따라서 시간은 증거의 일부이며, 정확히 서명되었더라도 오래된 파일이 곧 현재 설정으로 받아들일 수 있는 것은 아닙니다.

RFC 9718은 다이제스트 데이터와 함께 DNSKEY 공개 키와 플래그를 담는 선택적publickeyinfo도 허용합니다. 이 추가 표현은 처리기가 DNSKEY 자료를 직접 구성할 수 있게 해 줍니다. 동시에 일관성 의무도 만듭니다. 공개 키 정보와 다이제스트가 일치하지 않으면 해당KeyDigest는 사용되어서는 안 됩니다. 유효한 CMS 서명이 내부의 모순을 치유할 수는 없습니다.

이 선택적 필드에 대한 지원 자체가 로컬 역량입니다.publickeyinfo를 이해하는 처리기와 그렇지 않은 처리기는 같은 진본 XML을 읽고 서로 다른 후보 집합을 만들 수 있습니다. 입력의 출처가 균일한 해석을 보장하지는 않습니다. 소프트웨어 버전, 파서 동작, 출력 표현은 운영 기록에 남아야 합니다.

XML의source속성조차 의도적으로 겸손합니다. RFC 9718은 이를 참고용으로만 다룹니다. URL은 문서를 어디서 찾을 수 있는지 말할 수 있지만, 문서 안에 등장한다고 해서 권위를 부여하지는 않습니다. 이것이 위치 지정자와 명령 사이의 차이입니다.

마지막은 수용입니다. RFC는 검증기 운영자가 스스로 선택한 정책에 따라 공개된 앵커를 수용할지 결정할 수 있다고 말합니다. 이 문장은 실제로 코드가 돌아가는 곳에 책임을 남겨 둡니다. IANA는 공개하고, 인증서 시스템은 출처 확인을 지원하며, 구현자는 파싱하고, 벤더는 패키징하며, 운영자가 무엇을 리졸버의 신뢰 상태에 넣을지 결정합니다.

RFC 5011은 이 첫 번째 결정을 폐지하지 않습니다. 이미 앵커를 신뢰하는 검증기가 관찰과 홀드다운 조건을 거쳐 후속 키를 대역 내에서 학습하는 방법을 제공할 뿐입니다. 기존 신뢰가 전환을 인증합니다. 그것은 거슬러 올라가 이 방법을 가능하게 한 최초의 설치를 인증할 수는 없습니다.

현재의IANA 트러스트 앵커 페이지는 배포 표면을 구체적으로 보여 줍니다.root-anchors.xml이 앵커 데이터를 담고,root-anchors.p7s가 분리 서명을 담고,icannbundle.pem이 그 서명을 검증하는 데 쓰이는 인증서를 제공합니다. 페이지는 또한 벤더들이 업데이트를 배포하는 방식과 시점이 서로 다르다는 점을 밝힙니다. 따라서 하나의 공개 세트가 리졸버에 도달하기 전에 여러 기관의 릴리스 정책을 통과할 수 있습니다.

IANA의2024년 11월 형식 고지는 사용자에게 XML을 정기적으로 받아 자신의 시스템이 개정 형식을 처리할 수 있는지 시험해 보라고 요청했습니다. 이 조언은 실무적 경계를 드러냅니다. 공개의 성공이 배포의 성공은 아니라는 것입니다. 산출물이 진본이고 시의적절하더라도 다운스트림 파서가 거부하거나, 패키지가 오래되거나, 운영자가 수용하지 않을 수 있습니다.

라이브root-anchors.xml은 기계 판독 가능한 공개물이지, 어떤 특정 리졸버가 그 항목을 수용했다는 선언이 아닙니다.

NSRC의 약력은 Abley가 ICANN DNS 운영을 이끌고 루트 DNSSEC 배포에 참여한 경력을 기록하고 있습니다. 그 경험이 중요한 이유는 RFC 9718이 인접한 증명들이 서로를 사칭하도록 내버려두지 않겠다는 운영자의 거부처럼 읽히기 때문입니다. 이 문서가 Abley에게 루트에 대한 주권을 부여하지 않으며, RFC는 그의 일방적 정책도 아닙니다. 그 가치는 어떤 단일 서명도 전체 결론을 소유하지 않는 시스템을 기술하는 데 있습니다.

따라서 방어 가능한 트러스트 앵커 수용 기록은 다섯 가지 답을 보존해야 합니다. 파일의 출처와 내용이 검증되었는가, 어떤 메커니즘으로? 항목이 유효 구간 안에 있었는가? 다이제스트와 공개 키 표현이 일치했는가? 어떤 파서와 변환이 후보 앵커를 만들었는가? 누가, 어떤 정책 아래서, 어느 검증기에 그 후보를 수용했는가? “서명이 유효하다”는 말은 첫 번째 질문에만 답합니다.