요약

  • 인증된 암호화 DNS 세션은 범위가 제한된 전송 영수증일 뿐이며, 재귀 리졸버가 무엇을 저장하고, 상관 분석하고, 공유하고, 필터링하고, 상류로 전달하는지를 증명하지 않습니다.
  • RFC 8932의 재귀 운영자 프라이버시 성명서(RPS)는 이러한 선택을 비교 가능하게 만들지만, 신뢰할 수 있는 프라이버시 주장에는 전송, 처리, 저장·접근, 제3자 공개 각각에 대해 시간 범위가 정해진 별도의 증거가 여전히 필요합니다.

사용자가 설정 하나를 바꾸면 브라우저에 익숙한 안전 표시가 나타납니다. 이제 DNS가 TLS, HTTPS 또는 QUIC를 통해 지정된 재귀 리졸버로 전달됩니다. 로컬 네트워크의 수동 관찰자는 질의를 쉽게 들여다볼 수 있게 하는 통로를 잃습니다. 클라이언트는 해당 서비스를 인증할 수 있습니다. 이는 미적인 것이 아니라 실질적인 이득입니다.

그런 다음 암호화된 연결은 리졸버에서 끝납니다.

그 엔드포인트 반대편에서 운영자는 원칙적으로 질의와 그 사용자에게 붙은 전송 식별자를 볼 수 있습니다. 어떤 필드를 기록할지, 얼마나 보관할지, 누가 읽을 수 있는지, 세션을 상관 분석할지, 어떤 응답을 바꿀지, 어떤 정보를 전달할지 결정할 수 있습니다. 이러한 선택 중 어느 것도 자물쇠 아이콘에서는 보이지 않습니다. 암호화는 경로상의 관찰자를 바꾸었을 뿐, 운영자를 없애지는 않았습니다.

바로 이것이 RFC 8932,DNS 프라이버시 서비스 운영자를 위한 권고의 유용한 경계입니다. 2020년 10월에 BCP 232로 발행된 이 문서는 Sara Dickinson, Benno Overeinder, Roland van Rijswijk-Deij, Allison Mankin이 함께 만든 공동 저작물입니다. Dickinson의 IETF 프로필은 이 RFC를 여덟 개의 RFC 중 하나로 기재하고 그녀를 프라이버시 증진 및 평가 리서치 그룹(Privacy Enhancements and Assessments Research Group)의 공동 의장으로 기록합니다. RIPE Labs는 그녀를 Sinodun IT의 공동 설립자로 밝힙니다. 이 기록들은 참여와 지속적인 DNS 활동을 입증할 뿐, 어떤 리졸버 배포에 대한 단독 발명이나 통제를 입증하지는 않습니다.

RFC 8932는 두 가지 일을 동시에 합니다. 암호화 DNS를 제공하는 서비스를 위한 운영 관행을 권고하고, 재귀 운영자 프라이버시 성명서(RPS)를 제안합니다. RPS는 운영자가 자신이 하는 일을 설명할 수 있는 공통 뼈대를 제공합니다. 독자가 주장된 속성과 측정 가능한 속성을 비교할 수 있게 해줍니다. 이 문서는 의도적으로 법률 자문도, 보편적인 프라이버시 정책도, 자동 컴플라이언스 인증서도 아닙니다.

이 구분이 중요한 이유는 “암호화 DNS”가 더 긴 트랜잭션의 한 부분만 가리키기 때문입니다.

첫 번째 영수증은 클라이언트-리졸버 전송에 관한 것입니다. 여기에는 엔드포인트와 인증 이름, 프로토콜, 인증서 결과, TLS 또는 QUIC 버전, 패딩 구성, 가용성, 평문으로의 폴백 여부가 기록될 수 있습니다. RFC 8310은 DNS over TLS의 사용 프로필을 설명하고, RFC 8484는 DNS over HTTPS를 정의하며, RFC 9250은 이후 전용 QUIC 연결을 통한 DNS를 정의합니다. 각각은 리졸버까지의 링크를 보호할 수 있습니다. 그러나 어느 것도 운영자가 복호화 이후 도착하는 내용을 잊어야 한다고 규정하지 않습니다.

전송은 응답 인증을 대신하지도 않습니다. RFC 8932는 DNSSEC과 암호화 전송이 서로 다른 문제를 해결한다고 명시합니다. 자체적으로 DNSSEC 검증을 수행하지 않는 클라이언트에게, 인증된 암호화 연결은 리졸버가 검증을 수행했는지도, 반환된 데이터가 DNSSEC으로 인증되었는지도 증명하지 않습니다. 클라이언트는 여전히 리졸버의 Authentic Data 비트를 신뢰하고 있을 수 있습니다. 따라서 TLS 인증서는 DNSSEC 주장에 대한 잘못된 영수증입니다.

두 번째 영수증은 서비스 내부의 처리에 관한 것입니다. 어떤 검증 모드가 실행되었는가? 리졸버가 응답을 변경했는가? 예외 또는 위협 정책이 발동했는가? 어떤 캐시 동작이 적용되었는가? 서비스가 IP 주소, 재개 토큰, HTTP 특성 또는 반복 질의 패턴을 통해 여러 세션을 한 사용자에게 묶었는가? RFC 9076은 암호화된 질의와 응답조차도 재귀 리졸버를 떠나는 평문 요청과 상관될 수 있음을 지적합니다. 고정된 암호화 리졸버는 보이는 상대를 예측 가능하게 만들면서 동시에 한 사용자를 네트워크 전반에서 더 쉽게 식별 가능하게 만들 수 있습니다.

필터링은 암호화 속성이 아니라 운영자의 결정이기 때문에 이 처리 기록에 속합니다. RFC 8932는 RPS가 네트워크 보안, 구속력 있는 법률, 자발적 법적 리스크 정책, 상업적 이유 또는 기타 어떤 이유로든 응답이 필터링되거나 변경되는지를 공개하도록 요구합니다. 필터 목록이 어떻게 만들어지고 어떤 제3자 소스가 이를 공급하는지도 물어봅니다. 따라서 “보안 DNS”는 기밀 채널과 변경된 응답을 동시에 지칭할 수 있습니다. 독자에게는 두 사실이 모두 필요합니다.

세 번째 영수증은 저장과 접근에 관한 것입니다. RFC 8932는 보관을 최소화하거나 피할 것을 권고합니다. 데이터를 보관해야 하는 경우 암호화, 그리고 가능한 한 집계, 가명 처리 또는 익명화를 권고합니다. 로그 보관 기간은 운영 또는 규제상 필요 이상으로 길어서는 안 되며, 접근은 필요한 인력으로 제한되어야 합니다.

이는 절제된 권고이지만, 그 동사들이 증거 공백을 드러냅니다. 정책은 “7일”이라고 말할 수 있고, 삭제 로그는 예정된 한 번의 삭제 완료를 보여줄 수 있습니다. 역할 정의는 “운영 담당자만”이라고 말할 수 있고, 접근 기록은 어떤 계정이 데이터셋을 열었는지 보여줄 수 있습니다. 암호화 저장 설정은 보관 중 암호화를 보여줄 수 있습니다. 이러한 관찰 중 어느 것도 다른 것을 증명하지 않습니다. 또한 가명 처리를 무심코 익명화로 불러서는 안 됩니다. 안정적인 대체 값은 장기 프로필을 가능하게 하는 연결 가능성을 그대로 남길 수 있고, 매핑이나 방법이 확보되면 되돌릴 수 있는 방식도 있습니다.

네 번째 영수증은 리졸버를 떠나는 데이터에 관한 것입니다. 재귀 DNS는 일반적으로 질의를 다른 리졸버나 권한 서버로 전달합니다. RFC 8932는 각 서버가 전체 이름 중 필요한 것보다 적게만 알도록 QNAME 최소화를 권고합니다. 이 기법은 이후 RFC 9156이 갱신했습니다. 이 문서는 또한 가능한 한 EDNS Client Subnet 사용을 피하고, ECS를 전송해야 한다면 운영상 실현 가능한 최단 접두어를 사용하고 정책을 명확히 공개할 것을 권고합니다.

바로 이 지점에서 서비스는 첫 홉을 보호하면서 두 번째 홉에서 세부 정보를 누출할 수 있습니다. 외부 테스트는 특정 질의가 최소화되었거나 ECS가 없었다는 것을 관찰할 수 있습니다. 이는 시간, 관찰 지점, 테스트 사례를 가진 귀중한 증거입니다. 그러나 모든 목적지, 포워더, 정책 분기가 같은 방식으로 동작했다는 증명은 아닙니다. 질의가 저장된 이후의 미공개 데이터 전송을 드러낼 수도 없습니다.

따라서 RFC 8932는 RPS가 하나의 슬로건 이상을 다루도록 요구합니다. 정책 부분은 IP 주소가 개인 데이터로 취급되는지, 무엇을 수집·보관·공유·판매·임대하는지, 최소화 방법과 전송 조건, 예외, 관련 조직과 재원, 다른 개인 정보와의 상관 분석, 필터링을 명시해야 합니다. 실천 부분은 현재 클라이언트 대면 전송 방식과 인증, 상류 동작, 예외 사항, 지원, 관련 처리 정보를 설명해야 합니다.

RPS는 주장과 증거를 연결하는 지도로 취급될 때 가장 강력합니다. “QNAME을 최소화한다”는 문장은 구현 구성과 독립 프로브를 가리킬 수 있습니다. 보관 약속은 수명 주기 관리와 삭제 결과를 가리킬 수 있습니다. 접근 제한은 역할 정책과 감사된 접근 기록을 가리킬 수 있습니다. 제3자 공개에 대한 성명은 수신자, 목적, 필드, 기간, 만료를 명시할 수 있습니다. 투명성 보고서와 범위가 지정된 제3자 감사는 지도를 더 넓게 검증할 수 있습니다.

그러나 지도는 영토가 아닙니다. 감사에는 기간, 표본, 범위가 있습니다. 프로브에는 관찰 지점이 있습니다. 투명성 보고서는 정해진 접근 권한을 가진 사람이 작성합니다. 공개된 RPS는 실제 구성보다 늦을 수 있습니다. 정직한 결론은 프라이버시가 알 수 없다는 것이 아니라, 각 주장에는 그에 맞는 증인과 그에 맞는 한계가 있다는 것입니다.

Dickinson과 공저자들은 운영자에게 이러한 한계를 드러내는 어휘를 제공했습니다. 지속적인 기여는 또 하나의 자물쇠 아이콘보다는 화려하지 않지만 운영상 더 유용합니다. 프라이버시 질문을 “파이프가 암호화되어 있는가?”에서 “징의가 도착한 후 누가 각 결정을 내릴 수 있는가, 어떤 증거가 남는가, 그리고 그 약속을 얼마나 빨리 검증할 수 있는가?”로 옮겨 놓았습니다.

출처