요약
- 새로운 DNS Filtering Transparency 초안에는 데이터베이스 운영자 식별자와 인시던트 식별자가 담기며, 필터링 사건이 왜 발생했는지에 대한 인증된 기술이 아닙니다. 이 초안은 리졸버가 공개할 내용을 직접 선택할 수 있도록 허용하고, 리졸버가 어떤 경험을 오해를 낳는 정보와 연결지을 수 있음을 인정합니다.
- 두 번째 결정은 이를 소비하는 애플리케이션 내부에 있습니다. 애플리케이션은 레지스트리 사본을 로컬에 유지하고, 지원하거나 신뢰할 데이터베이스 운영자를 선택하며, 사용자에게 참조 링크를 보여줄지 결정합니다. 등록된 식별자는 해석 틀을 제공할 뿐, 인시던트나 그 이면의 정책을 보증하지 않습니다.
- 세 번째 결정은 사용자에게 속합니다. 인시던트 페이지를 가져오는 행위는 IP 주소와 민감한 이름에 대한 관심을 동시에 드러낼 수 있기 때문입니다. 그러므로 방어 가능한 공개 연쇄 영수증은 리졸버 선택, 애플리케이션 표시, 사용자 검색을 별개의 행위로 보존해야 합니다.
조회 실패 후 브라우저가 다음 문장을 보여주는 장면을 상상해 보십시오. 이 사이트는 법적 요청에 따라 사용자의 DNS 리졸버에 의해 차단되었으며, 자세한 정보는 링크에서 확인할 수 있다는 문장입니다. 이 문장은 단일하게 보입니다. 원인 하나, 행위자 하나, 목적지 하나가 있는 셈입니다. 불투명한 오류보다 권위 있고, 일반 코드보다 유용하게 느껴집니다.
그러나 이 문장은 작은 출판 시스템의 끝자락입니다. 문장이 나타나기 전에, 리졸버는 필터링 데이터베이스에 대한 참조를 하나 이상 붙일지 결정합니다. 애플리케이션은 어느 데이터베이스 운영자를 인식할지, 그 결과로 나온 참조를 표시할지 결정합니다. 사용자는 페이지를 가져올지 결정하며, 이를 통해 DNS 교환 자체가 반드시 해당 데이터베이스 운영자에게 드러내지 않은 정보를 노출할 수 있습니다.
이것들은 하나의 결정을 둘러싼 구현 세부사항이 아닙니다. 통제자와 증거와 유인이 서로 다른 세 가지 결정입니다. 이를 "DNS가 차단을 설명했다"로 압축하면, 누가 그 계정을 선택했는지, 누가 그 표시를 보증했는지, 누가 열어보는 데 따른 프라이버시 비용을 감수했는지가 가려집니다.
초안이 담는 것은 판정이 아니라 참조다
2026년 8월 1일 게시된draft-ietf-dnsop-filtering-transparency-00은 Structured DNS Error 작업에 의도적으로 작은 추상화를 하나 추가합니다. 필터링된 DNS 응답은fdbs목록을 담을 수 있습니다. 목록의 각 항목은 필터링 인시던트 데이터베이스 운영자의 식별자인db와, 그 데이터베이스 내 항목의 식별자인id를 짝지어 담습니다. 목록 내 모든 짝은 동일한 근본 인시던트에 관한 것이어야 합니다.
애플리케이션은 리졸버로부터 임의의 URL을 받지 않습니다. 대신 제안된 IANA 레지스트리의 로컬 사본에서 데이터베이스 운영자 식별자를 조회하고, URI 템플릿을 얻어 인시던트 식별자를 치환한 뒤, 확장된 링크를 제시할 수 있습니다. 이는 뚜렷한 위험 하나를 줄입니다. 신뢰할 수 없는 리졸버가 DNS 응답에 URL을 넣는 것만으로 사용자 인터페이스에 원하는 링크나 문구를 직접 삽입할 수 없게 됩니다.
이는 유용한 제약입니다. 그러나 인시던트에 대한 인증은 아닙니다. 초안의 보안 절은 이 메커니즘이 애플리케이션이 관찰한 필터링 경험이 실제로 제시된 정보와 연관되어 있음을 증명하지 않는다고 말합니다. 리졸버를 장악한 당사자는 기존의 운영자·인시던트 식별자를 재사용해 실제 존재하는 페이지로 확장되도록 하면서, 그 페이지를 사용자의 조회와 잘못 연결지을 수 있습니다.
이 구분은 근본적입니다. 역참조 가능한 기록은 해당 위치에 기록이 존재한다는 것을 증명합니다. 그러나 리졸버가 올바른 기록을 골랐다는 것, 데이터베이스 기술이 완전하다는 것, 명령이 유효하다는 것, 필터가 의도한 대상과 일치했다는 것, 사건이 페이지가 시사하는 관할권이나 시점에 발생했다는 것은 증명하지 않습니다. 프로토콜은 어떤 기술(계정)에 대한 참조를 전송할 뿐, 그 기술을 확정된 사실로 만들지 않습니다.
초안 자체도 권한에 신중합니다. 이는 활성 DNSOP 워킹 그룹 Internet-Draft이지 RFC가 아니며, 현재 의도된 RFC 상태를 표기하지 않고 있습니다. 메커니즘은 변경될 수 있습니다. 거버넌스 기록은 논의 중인 작업이 RFC 시리즈의 권위를 조용히 빌려오지 않도록 그 상태를 명시해야 합니다.
리졸버는 공개 집합을 편집한다
첫 번째 통제 지점은 리졸버에 있습니다. 초안은 특정 정보를 전달할 의무가 없다고 명시합니다. 리졸버는 지원할 데이터베이스 제공자를 선택하며, 참조를 포함할지 언제 포함할지를 결정하는 메커니즘도 자유롭게 고를 수 있습니다.
이 재량은 리졸버를 고지의 편집자로 만듭니다. 데이터베이스 둘, 하나, 혹은 하나도 포함하지 않을 수 있습니다. 한 정책 범주에 대해서는 항목을 붙이고 다른 범주에는 붙이지 않을 수 있습니다. 내부 사건을 외부 인시던트 데이터베이스에 대응시키지 못할 수도 있고, 공개가 다른 의무와 충돌한다고 판단할 수도 있습니다. 이런 가능성들이 곧바로 부정행위는 아닙니다. 단지 송출되는 목록이 설명의 전수 조사가 아니라 선택된 집합이라는 뜻입니다.
따라서 부정적 추론이 중요합니다.fdbs항목이 없다는 것이 필터링이 없었다는 것, 인시던트 페이지가 없다는 것, 법적·조직적 지시가 관여하지 않았다는 것, 리졸버에 관련 기록이 없다는 것을 증명하지는 않습니다. 이는 다만 수신된 그 응답이 사용 가능한 항목을 제공하지 않았음만 확정합니다. 호스트 아키텍처가 필요한 DNS 응답 세부정보를 노출하지 않는 경우, 일부 애플리케이션은 구조화 오류 메커니즘 자체를 활용하지 못할 수 있습니다.
리졸버 측 영수증은 조회·응답 시각, 존재한다면 인증된 리졸버 관계, 적용된 Extended DNS Error 코드, 실제 송출된 운영자/인시던트 짝, 이를 선택한 정책 또는 기술 규칙, 그리고 선택 과정이 알고도 포함하지 않은 대안이 있었는지를 기록해야 합니다. 민감한 세부사항은 최소화하거나 통제된 접근 하에 둘 수 있습니다. 폐기할 수 없는 것은 선택이 발생했다는 사실입니다.
애플리케이션은 보이는 것을 편집한다
두 번째 통제 지점은 브라우저, 운영체제 등 소비하는 애플리케이션 안에 있습니다. 초안은 애플리케이션이 모든 등록된 데이터베이스 운영자를 신뢰할 것을 요구하지 않습니다. 구현체는 자체 레지스트리 사본을 유지하고, 서로 다른 운영자 집합을 지원하며, 어떤 메시지를 표시할지 판단해야 합니다. 리졸버 신원, 데이터베이스 운영자 신원, 로컬 설정이 모두 그 판단을 좌우할 수 있습니다.
이는 작은 렌더링 선택이 아닙니다. 어떤 기관의 기술(계정)이 사람에게 도달할 수 있는지를 결정합니다. 동일한 DNS 응답을 받은 두 사용자가 서로 다른 설명을 볼 수 있는 이유는, 각 애플리케이션이 서로 다른 데이터베이스 ID를 인식하고, 서로 다른 날짜의 레지스트리 스냅샷을 사용하고, 서로 다른 신뢰 목록을 적용하고, 호스트에서 서로 다른 DNS 데이터를 노출하기 때문입니다. 한 사람은 링크를 보고, 다른 사람은 실패만 볼 수 있습니다. 어느 화면만으로는 상류의 공개 집합 전체를 알 수 없습니다.
로컬 레지스트리 상태는 시간적 문제를 더합니다. 제안된 데이터베이스 레지스트리는 운영자 ID를 URI 템플릿에 대응시킵니다. 등록 연락처는 언제든 템플릿을 갱신할 수 있으며, 초안은 애플리케이션 사본이 갱신되기까지 상당히 긴 지연이 있을 수 있다고 경고합니다. 사용자가 무엇을 볼 수 있었는지 재구성하려면 오늘의 IANA 항목이나 오늘의 목적지 페이지가 아니라 그 시점에 사용된 레지스트리 스냅샷이 필요합니다.
등록 정책은 이 경계를 더 선명하게 합니다. 초안은 선착순 등록을 제안하며, IANA가 기만적이거나 무의미한 등록은 거부할 수 있는 여지를 둡니다. RFC 8126은 선착순 배정이 통상 형식과 고유성 확인 외의 실질 심사를 하지 않는다고 설명합니다. 등록은 "이 식별자에 어느 템플릿이 속하는가"에 답합니다. "이 운영자의 인시던트 기술이 정확한가"에는 답하지 않습니다. 이를 지원하고 신뢰하고 표면화할지에 대한 결정적 판단은 여전히 애플리케이션의 몫입니다.
따라서 애플리케이션 영수증은 레지스트리 스냅샷 날짜 또는 해시, 실제 확장된 템플릿, 신뢰 목록 버전, 응답에 연관지은 리졸버 신원, 수용하거나 억제한 항목, 그 판단의 사유 범주, 사용자에게 보인 문구나 화면 요소를 기록해야 합니다. 이 필드들이 없다면 최종 고지 화면의 스크린샷만으로는 누락된 맥락이 리졸버에서 왔는지, 로컬 레지스트리 캐시에서 왔는지, 애플리케이션 자체 정책에서 왔는지 설명할 수 없습니다.
사용자의 클릭은 공개 결정이다
세 번째 통제 지점은 고지가 화면에 나타난 후에 등장합니다. 인시던트 URL을 가져오면 데이터베이스 운영자가 사용자의 IP 주소와, 그 주소에서 특정 필터링된 이름을 조회하려 했다는 사실을 알게 될 수 있습니다. 민감한 도메인과 제한적 환경에서는 설명을 구하는 행위 자체가 설명을 구하는 사람에 대한 두 번째 관찰을 만들어냅니다.
초안은 이에 대해 엄격한 경계로 응답합니다. 애플리케이션이 프록시 같은 프라이버시 보호 메커니즘을 사용하지 않는다면, 명시적 사용자 행동 없이 인시던트 URL을 자동으로 가져와서는 안 됩니다. 또한 리졸버와 데이터베이스 운영자가 함께 움직이거나 한 주체가 두 역할을 동시에 차지하는 경우, 고유한 인시던트 ID를 부여해 요청 간 활동을 상관 분석할 수 있다고 경고합니다.
이는 "더 많은 정보 보기"를 동의 및 경로 선택의 문제로 바꿉니다. 클라이언트는 가져오지 않고도 참조가 존재한다는 것을 표시할 수 있습니다. 예상되는 목적지와 노출을 설명할 수 있습니다. 가능하다면 프록시 경로를 제공할 수 있습니다. 네트워크 행위는 사용자의 선택이 지배해야 하며, 기록은 민감한 이름과 신원의 새로운 저장소가 되어서는 안 됩니다.
영수증은 경계가 작동했음을 증명하기 위해 사용자 신원을 보존할 필요가 없습니다. 자동 가져오기가 없었다는 것, 직접 경로와 프라이버시 보호 경로 중 무엇이 제공되었는지, 검색 전에 명시적 행동이 있었는지, 기능 감사에 필요한 최소한의 텔레메트리를 기록하면 됩니다. 프라이버시 보호에 대한 감사가 장황한 로그를 통해 프라이버시 피해를 재현한다면 거버넌스는 실패한 것입니다.
구조화 오류는 이미 자동 신뢰를 거부한다
필터링 투명성 제안은 더 넓은 범위의 Structured Error Data for Filtered DNS 초안에 의존합니다. 그 작업은 기계 판독 가능한 설명 필드를 표시하거나 기록하거나 활용할 수 있게 하면서도, 적절한 검증 없이는 데이터를 자동으로 신뢰하거나 표시하거나 보안 결정에 영향을 주게 해서는 안 된다고 규정합니다. 구조화 교환에는 암호화된 DNS 전송을 요구하고, 사용자 모르게 제3자가 기록하거나 전송하는 행위를 제한합니다.
이 제약들은 건강한 분리를 드러냅니다. 구조는 정보를 처리 가능하게 할 뿐, 참이 되게 하지는 않습니다. 암호화는 수동적 관찰로부터 경로를 보호할 뿐, 종단점이 제공하는 모든 진술이 올바름을 확정하지는 않습니다. 등록된 JSON 이름은 문법을 안정화할 뿐, 기관적 권위를 부여하지는 않습니다. 새 데이터베이스 참조는 또 하나의 맥락 계층을 더하지만, 모든 계층은 각자의 증거 한계를 유지합니다.
RFC 7754는 더 오래된 아키텍처적 배경을 제공합니다. 차단 정책을 정하는 주체와 그것을 집행하는 주체를 구분하고, 법률·규제·운영자 규칙·구현이 여러 단계에서 원래 목적을 변형할 수 있다고 지적합니다. 오류를 바로잡기 위한 신속한 고지를 가치 있는 것으로 보면서도, 법적·윤리적 판단은 기술적 분석 밖에 둡니다. 새 초안은 설명에 이르는 경로를 개선할 뿐, 정책 수립 단계와 집행 단계를 단일 주체로 뭉개지 않습니다.
공개 연쇄 영수증
신뢰할 수 있는 구현은 세 개의 연결된 절로 이루어진 간결한 공개 연쇄 영수증을 산출해야 합니다.
리졸버 절은 응답 관찰, 존재한다면 인증된 리졸버 맥락, EDE 데이터, 송출된 운영자/인시던트 짝, 선택 규칙, 알려진 누락 상태를 식별해야 합니다. 애플리케이션 절은 레지스트리 스냅샷, 확장된 템플릿, 지원 운영자 및 신뢰 정책 버전, 표시 결정, 사용자 대면 문구 범주를 명시해야 합니다. 사용자 행동 절은 검색이 제공되었는지, 명시적 행동이 선행했는지, 프록시가 요청을 보호했는지, 가져오기가 성공했는지를 기록하되, 감사 목적에 필요한 범위를 넘어 민감한 이름이나 인물을 보존하지 않아야 합니다.
영수증은 불확실성을 보존해야 합니다. 리졸버 신원이 인증되지 않았다면 그렇게 밝혀야 합니다. 애플리케이션이 DNS 응답 세부정보에 접근할 수 없다면 그렇게 밝혀야 합니다. 레지스트리 사본이 낡았다면 현재 항목을 조용히 대체하지 말고 그 날짜를 기록해야 합니다. 인시던트 페이지가 나중에 바뀌었다면 현재 페이지를 사용자가 제안받았던 페이지인 것처럼 꾸며서는 안 됩니다. 정책이나 명령의 출처가 독립적으로 확보 가능하다면 별도의 증거로 연결해야 하며, 데이터베이스 식별자로부터 추론해서는 안 됩니다.
그런 영수증은 필터링을 정당화하지 않습니다. 공개 경로를 책임 가능하게 만듭니다. 운영자, 애플리케이션 공급자, 감사자, 영향을 받은 사용자가 설명이 어디에서 사라지고, 바뀌고, 새로운 정보를 노출했는지 찾아내게 합니다. 가장 중요한 것은, 실제로 어느 참여자도 내리지 않은 합의를 최종 화면이 흉내내는 것을 막는다는 점입니다.
출처
- DNS Filtering Transparency, WG 개정판 00
- Datatracker 상태
- 개정 이력
- DNSOP 워킹 그룹 헌장
- Structured Error Data for Filtered DNS, 개정판 27
- Structured Error Data Datatracker 상태
- RFC 8914 — Extended DNS Errors
- RFC 7754 — 인터넷 서비스 차단 및 필터링에 대한 기술적 고려사항
- RFC 6570 — URI Template
- RFC 8126 — IANA 고려사항 절 작성 지침
- Lu Heng — 최소 초기 명세와 인터넷 조율의 미래
- Lu Heng — The Policy Mirror
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





