요약

  • RFC 3445는 새로 발행되는 DNSKEY레코드를 DNSSEC 프로토콜 값 3으로 제한했습니다. 질의가 내부 하위 유형을 선택할 수 없고 서명이 RRset 전체를 덮었기 때문에, 무관한 애플리케이션 키가 DNS 인프라와 결합되는 문제가 있었기 때문입니다.
  • 그 이행은 의도적으로 비대칭이었습니다. 권한 있는 쓰기 측은 폐기된 값을 더 이상 추가하지 않았고, 읽는 측은 검증 과정에서 이를 유지하여 레코드 하나를 제거하더라도 서명이 무효화되거나 캐시 간 불일치가 생기지 않도록 했습니다.

범용 서랍이 하나의 실패 도메인이 되었다

최초의 야망은 쉽게 감탄할 만한 것이었습니다.RFC 2535는 DNS에KEY리소스 레코드를 부여했고, 그 RDATA는 플래그, 프로토콜 옥텟, 알고리즘, 공개 키를 담았습니다. 프로토콜 값 1은 이메일, 2는 IPsec, 3은 DNSSEC, 4는 TLS를 식별했습니다. 5부터 254까지는 계속 사용 가능했고, 255는 임의 프로토콜을 의미했습니다. 하나의 분산 이름 지정 시스템이 여러 공개 키를 위한 편리한 선반이 될 수 있었습니다.

그러나 DNS는 그 선반의 내부 라벨을 질의 언어에 노출하지 않았습니다. 클라이언트는KEY를 요청할 수 있었지만, DNS 서버에 이메일, IPsec 또는 DNSSEC 하위 유형만 요구할 수는 없었습니다. 그 소유자 이름의 모든 응답은 결국KEYRRset 전체를 반환했습니다. DNSSEC은 그 RRset을 개별 목적별 부분집합이 아니라 집합 전체로 서명했습니다. 이 컨테이너는 의도된 용도로는 복수였지만, 검색과 암호학적 범위로는 단수였습니다.

RFC 3445는 2002년 12월에 Donald Eastlake와 Olafur Gudmundsson이 발행한 문서로, 제한적인 실험적 배포 이후의 결과를 기술했습니다.평문,RFC Editor 기록,Datatracker 파일,이력,참고문헌,이후 인용,정오표 검색이 문서적 흔적을 확립합니다. 이들은 혼합된 집합을 발행한 존이 얼마나 되었는지, 어떤 리졸버가 올바르게 동작했는지는 확립하지 않습니다.

한 비트를 검토하기도 전에 키들은 달랐다

RFC 3445는 DNSSEC 키와 애플리케이션 키가 서로 다른 운영 세계에 속하는 여섯 가지 방식을 나열했습니다. 목적이 달랐습니다. 서로 다른 관리자가 이를 통제할 수 있었습니다. 인증 규칙이 달랐습니다. 권한 있는 네임서버가 응답에 이를 포함할 이유가 달랐습니다. 리졸버는 이를 서로 다르게 취급해야 했습니다. 오동작이나 침해가 만들어내는 결과도 달랐습니다.

이들은 메타데이터적 사소함이 아니었습니다. DNSSEC 키는 DNS 데이터 무결성에 필수적입니다. 애플리케이션 키는 DNS 자체에는 본질적 의미가 없습니다. 이들을 결합하면 RRset이 무관한 애플리케이션마다 커지고, 응답이 커지고, 본래 독립적이던 교체(로테이션) 일정이 동기화되며, DNS 관리자가 통제하지 않을 수도 있는 재료를 운반하도록 요구했습니다.

위험한 오류는 단순한 볼륨이 아니라 의미론적이었습니다. 공개 키의 존재는 인식하면서 프로토콜 필드를 강제하지 않는 소프트웨어는 침해된 애플리케이션 키를 존 키로 오인할 수 있었습니다. 암호학은 잘못된 키에게 잘못된 명제를 증명하도록 요구하는 검증자를 구원할 수 없습니다. 잘 구성된 레코드조차 소비자가 그리지 않은 신뢰 경계를 넘을 수 있습니다.

수리는 쓰기 경로를 닫았다

RFC 3445는 새로운 권한 있는KEY데이터에 대해 프로토콜 값 3만 허용하도록 했습니다. 존 키 비트인 비트 7을 제외한 모든 플래그 비트를 예약했습니다. 값 1, 2, 4, 255는 예약되었고, 한때 개방되어 있던 다른 애플리케이션용 범위도 예약되었습니다. 새 프로토콜 옥텟 할당은 표준 행동(Standards Action)을 통해서만 가능하도록 닫혔습니다.

이 축소는RFC 2930,RFC 2931과 관련된 트랜잭션 보안, 그리고RFC 3007의 보안 동적 업데이트와 관련된 용도를 포함해 DNSSEC의 존 키와 비존 키 구분을 보존했습니다. 오래된 호스트 대 사용자 플래그 구분은 보존하지 않았고, 애플리케이션 키의 지속적인 발행 호환성을 약속하지도 않았습니다. 그 애플리케이션들은 더 잘 정의된 레코드나 다른 메커니즘이 필요했습니다.

이것은 DNS가 애플리케이션 키 자료를 결코 발행해서는 안 된다는 주장이 아니라 구조적 감축이었습니다. RFC 3445는 다른 RR 유형을 개방된 상태로 명시적으로 남겼습니다. 이후의 레코드들이 더 구체적인 컨테이너를 보여줍니다. SSH 호스트 키 지문을 위한SSHFP, 인증서를 위한CERT, TLS 연관을 위한TLSA가 그것입니다. 이들은 이후의 맥락일 뿐, 한 편의 짧은 RFC가 모든 후속 설계를 낳았다는 증거가 아닙니다.

읽는 측은 역사를 단순히 버릴 수 없었다

가장 시사적인 규칙은 반대 방향을 겨냥했습니다. 쓰는 측은 3이 아닌KEY값 생성을 중단해야 했지만, 읽는 측은 그 오래된 레코드를 RRset의 구성원으로 수용하도록 권고받았습니다. 리졸버는 이를 DNS 데이터 인증에 사용해서는 안 됩니다. 그러나 서명 검증 전에 이를 제거해서도 안 됩니다.

용도가 폐기된 것을 왜 보존하는가? 서명이 완전한 RRset을 덮었기 때문입니다. 리졸버가 애플리케이션 키 레코드 하나를 조용히 버린 뒤 원래 집합에 대해 만들어진 서명을 검증한다면, 서로 다른 바이트를 검증하게 됩니다. 서명은 실패합니다. 어떤 캐시는 레코드를 유지하고 어떤 캐시는 필터링한다면, 네트워크는 명목상 같은 서명된 집합에 대해 일관되지 않은 버전을 유지할 수도 있습니다.

따라서 "DNS 인증에서는 무시"와 "암호학적 검증 전에 삭제"는 동의어가 아닙니다. 하나는 권한에 대한 결정이고, 다른 하나는 검증되는 증거 자체를 변형합니다. RFC 3445는 의미적 사용과 집합 보존을 분리했습니다. 이 구분은 여전히 강력한 이행 패턴으로 남습니다. 오래된 형식의 생성을 중단하고, 안전하게 검증하고 이동할 수 있을 만큼 계속 파싱하며, 더 이상 마땅히 받아야 할 권한은 부여하지 않는 것입니다.

DNSSEC은 나중에 그 경계를 더 명확히 명명했다

2005년 DNSSEC 규격 계열, 즉RFC 4033,RFC 4034,RFC 4035는 RFC 2535 계열을 폐기하고DNSKEY레코드를 사용했습니다. 그 이름 자체가 더 이상 범용 키 서랍을 내세우지 않았습니다. 현재의IANA DNS 파라미터가 그 결과로 나타난 레지스트리 상태를 보여줍니다.

그 레코드는 오늘 어떤 상징적 값과 정책이 등록되어 있는지 증명할 수 있습니다. 그러나 레거시KEY데이터가 사라졌다는 것, 모든 파서가 프로토콜 의미론을 적용한다는 것, 캐시가 수렴했다는 것, 특정 키가 신뢰할 수 있었다는 것은 증명할 수 없습니다. 표준 문서는 규칙이 작성되었음을 증명합니다. 존 스냅샷은 한 시점에 데이터가 제공되었음을 증명합니다. 패킷 캡처는 한 응답이 하나의 관측 지점을 통과했음을 증명합니다. 리졸버 테스트는 하나의 구현 경로를 증명합니다. 보안 결과는 여전히 다른 증거를 요구합니다.

하나의 신뢰 모델을 공유하는 가장 작은 컨테이너

Lu Heng의현실 계층 규율은 최초 설계가 왜 매혹적이었는지 설명하는 데 도움이 됩니다. 인코딩, 레지스트리 할당, 서명 유효성, 행정적 권한, 배포, 안전한 결과는 모두 "키가 DNS에 있다"처럼 보일 수 있으면서도 여전히 분리된 사실입니다. 이들을 하나의 레코드에 넣는다고 신뢰 모델이 수렴하지 않았습니다.

실행 코드 우선도 중요합니다. RFC 3445는 추상화가 지저분해서 실험을 거부한 것이 아니라, 제한된 배포를 통해 발견된 문제에 대응했습니다. 코드는 질의 세분성, 서명 범위, 운영 소유권이 상상된 범용 컨테이너와 맞지 않음을 드러냈습니다. 올바른 교훈은 실행 코드가 자동으로 지배한다는 것이 아니라, 깔끔한 모델이 관측된 경계 비용을 무시할 수 없다는 것입니다.

최소 초기 명세원칙은 긍정적 설계를 제안합니다. 참여자들이 실제로 목적과 검증 규칙을 공유하는 좁은 공용 프리미티브를 표준화하라는 것입니다. 자발적 애플리케이션 생태계가 목적별 레코드를 선택하도록 하고, DNSSEC의 인프라 키를 그들의 거버넌스에 강제로 징집하지 말아야 합니다. 이것은 편집적 해석이며, 저자들의 개인적 의도에 대한 증거가 아닙니다.

RFC 3445의 지속적인 통찰은 더 작고 날카롭습니다. 공통의 와이어 형태는 공통의 신뢰 도메인이 아니라는 것입니다. 질의, 서명, 캐시가 무관한 객체들을 하나의 집합으로 함께 움직이도록 강제할 때, 그 집합 경계는 원래 형식이 이를 인정했는지와 무관하게 보안 및 거버넌스 경계가 됩니다.

출처