요약

  • RFC 9953은 자신의 보안 컨텍스트를 공유하는 DoC 클라이언트와 DoC 서버 사이의 DNS 메시지를 보호할 수 있으며, 서버의 상위 DNS 홉을 노출하거나 인증하지 않습니다.
  • 신뢰할 수 있는 디스커버리, 컨텍스트 설정, 응답 처리, 상위 전송, DNSSEC 검증, 애플리케이션 수용은 각각 별개의 시점별 기록입니다.

제약된 기기는 CoAP FETCH 요청으로 DNS 질의를 보내고 CoAP 응답으로 DNS 회신을 받을 수 있습니다. DTLS, TLS 또는 OSCORE가 이 교환을 보호할 수 있습니다. 이것이 유용한 이유는 바로 주장의 범위가 좁기 때문입니다. 해당 컨텍스트의 양 끝점 사이에서 메시지가 보호되었다는 것입니다.

다음 홉은 별도의 장부에 속합니다. RFC 9953은 DoC 서버가 보호 없이 상위 DNS 인프라와 통신할 수 있다고 명시하며, 그 예로 DNS over UDP를 듭니다. 대신 별도의 보호된 컨텍스트를 사용할 수도 있지만, 그 사실은 프로토콜 수준에서 DoC 클라이언트에게 불투명합니다. 따라서 녹색 클라이언트-서버 보안 표시만으로는 서버가 어떻게 권한 서버, 캐시, 재귀 리졸버 또는 포워더에 도달했는지 증명할 수 없습니다.

서버 선택도 같은 절제가 필요합니다. 클라이언트는 서버와 리소스를 알아야 하며, 자동 구성은 신뢰할 수 있는 출처에서 제공되어야 합니다. 이는 구성 출처에 대한 주장은 뒷받침하지만, 해당 서버가 올바른 재귀 운영자라거나 이 응답에 대해 DNSSEC을 검증한다거나 그 이름을 사용하는 모든 애플리케이션이 승인했다는 단정은 뒷받침하지 않습니다. RFC 9953은 서버 측 DNSSEC 검증에 대한 신뢰가 어떻게 표현되는지는 자신의 범위 밖이라고 밝힙니다.

실무 기록에는 연결 지점이 있습니다. 디스커버리 출처와 시점, 선택된 URI, 협상되거나 설정된 보안 컨텍스트, 질의 및 응답 식별자, 서버 응답, 주장이 있을 경우의 상위 증거, 검증 상태, 그리고 클라이언트 또는 애플리케이션의 결정이 그것입니다. 이러한 연결 지점을 놓아버리면 진행 중인 증거가 친근한 라벨로 대체됩니다. Amsüss는 이 표준의 공동 저자 중 한 명이지, 이름이 알려진 리졸버나 배포를 운영하는 당사자가 아닙니다.

출처