Mozilla의 숨겨진 보안 경계: 퍼블릭 서픽스 리스트가 실행 코드가 되는 방법

요약

• DNS 기록은 위임을 담당하지만, 서로 무관한 사용자들 사이의 행정적·보안 경계는 담당하지 않습니다. 퍼블릭 서픽스 리스트는co.uk,github.io같은 이름을 그 아래에서 서로 다른 주체가 운영할 수 있는 경계로 취급하도록 소비 소프트웨어에 알려 주는 방식으로 이 공백을 메웁니다.
• 이 목록은 ICANN, IANA, IETF가 관리하지 않습니다. 자원봉사자들이 공개 저장소를 통해 관리하며, 레지스트리 및 사영 도메인 변경에 대한 검증 규칙을 둡니다. 그 실질적 권위는 DNS를 지배한다는 주장이 아니라 브라우저·표준·라이브러리의 채택에서 나옵니다.
• 병합이 이루어져도 즉시 전 세계에 동일한 결과가 반영되지는 않습니다. 애플리케이션마다 서로 다른 스냅샷을 내장하고, 갱신 속도와 포함 섹션이 다르며, 때로 자체 규칙을 추가합니다. 따라서 이 목록은 중요한 조정 기록이지만 보편적이거나 자동 집행되는 보안 경계는 아닙니다.
• 방어 가능한 모델은 얇고 관측 가능한 모델입니다. 경계 변경을 요청하는 주체를 인증하고, 공개된 결정 기록을 남기며, 기계 판독 가능한 릴리스를 공개하고, 각 구현자가 소비 방식을 스스로 결정하게 하며, 전파를 측정하고, 목록 관리를 호스팅 사업이나 도메인 보유자 규제의 허가증으로 만들지 않는 것입니다.

분석

도메인 이름에 없는 사실

세 개의 이름을 생각해 봅시다:com,co.uk,github.io. 이들은 DNS 트리에서 서로 다른 위치를 차지합니다.com은 최상위 도메인입니다.co.uk는 국가 코드 최상위 도메인uk아래에 있습니다.github.io는 많은 사용자에게 서브도메인을 제공하기 위해 사적으로 등록된 도메인입니다. 그런데도 소프트웨어는 이 셋에 대해 같은 실용적 질문을 갖습니다. 하나의 독립적으로 통제된 사이트가 어디서 끝나고 다른 사이트가 시작되는가?

DNS는 그 질문에 답하지 않습니다. DNS는 레코드를 반환하고, 위임을 따라가고, 배치된 곳에서 DNSSEC으로 데이터 출처를 증명할 수 있습니다. 그러나 “이 지점 아래 레이블들은 상호 신뢰하지 않는 주체들에 속한다”는 보편적 표지를 담지 않습니다. IETF의 Domain Boundaries 워킹그룹 차터는 문제를 분명히 밝혔습니다. 행정 관계는 이름이나 DNS의 공개 운영 표현으로부터 알 수 없으며, 정답이 항상 가장 오른쪽 두 레이블을 비교하는 것은 아니라는 것입니다.

이 부재가 중요한 이유는, 브라우저가 사람이 기업 지배 구조를 조사하기 전에 판단을 내려야 하기 때문입니다. 서버가 브라우저에게 상위 도메인에 대한 쿠키 저장을 요청하면, 브라우저는 그 요청이 하나의 사이트 안에 머무는지 아니면 공유 네임스페이스로 넘어가는지 판단해야 합니다.github.io아래 모든 테넌트가 하나의 등록 가능한 사이트로 취급된다면, 어떤 테넌트는 다른 테넌트와 공유되는 수준에 상태를 설정하려 할 수 있습니다.

반대로co.uk가 등록 가능한 조직으로 취급된다면, 무관한 영국 등록인들이 하나의 정책 영역으로 묶일 수 있습니다. 또한 모든 서브도메인 경계가 조직을 분리한다고 가정하면, 평범한 사이트들이 자신의 호스트들 사이에서 쿠키와 정책을 합법적으로 공유하던 방식을 잃게 됩니다.

퍼블릭 서픽스 리스트(PSL)는 이 분류의 부재를 채웁니다. 그 자체 정의에 따르면 퍼블릭 서픽스란 그 아래에서 인터넷 사용자가—또는 과거에—이름을 등록할 수 있는 도메인입니다. WHATWG URL 표준은 구체적 예를 듭니다:github.io는 퍼블릭 서픽스이고,whatwg.github.io는 등록 가능한 도메인입니다. 이 분류는 새로운 DNS 위임이 아니라, 위임된 이름이 어떻게 사용되는지에 대한 애플리케이션의 지식입니다.

이 구분이 첫 번째 통제 경계입니다. IANA의 루트 존 기록은 어떤 최상위 도메인이 존재하고 운영 주체가 누구로 등재되어 있는지 답합니다. 레지스트리의 기록은 그 존 아래 무엇이 등록되었는지 답합니다. PSL은 소비 소프트웨어에게 다른 질문에 답합니다. 어느 레이블에서 무관한 행정 통제가 시작될 수 있다고 가정해야 하는가? 이 기능들을 혼용하면 거짓 권위가 만들어집니다. 퍼블릭 서픽스 등재는 도메인을 이전시키거나, 네임서버를 바꾸거나, 등록을 만들거나, 재산을 부여하지 않습니다. 참여 소프트웨어가 경계를 해석하는 방식을 바꿀 뿐입니다.

쿠키 규칙이 목록을 작동 가능하게 만들었다

이 목록의 가장 이해하기 쉬운 용도는 쿠키 격리입니다. 2011년의 HTTP 상태 관리 메커니즘인 RFC 6265는 퍼블릭 서픽스를 거부하도록 설정된 사용자 에이전트는, 좁은 호스트 동일성 예외를 제외하고, Domain 속성이 퍼블릭 서픽스인 쿠키를 거부해야 한다고 규정합니다. 이유는 구체적입니다. 검사가 없으면 공유 서픽스 아래에서 공격자가 트리에서 너무 높은 수준에 쿠키를 설정해 다른 등록인의 무결성을 침해할 수 있습니다. 이 RFC는 최신 목록 사용을 권고하며 Mozilla가 관리하는 자원을 가리킵니다.

현재의 RFC 6265bis 초안은 같은 운영 교훈을 유지하면서 위험을 더 명시적으로 만듭니다. 쿠키 경계는 사이트의 등록 가능 도메인에 의존하고, 그것은 다시 퍼블릭 서픽스에 의존합니다. 낡은 목록은 악의적 또는 민감한 쿠키가 등록 가능 도메인 사이로 새어 나가게 할 수 있습니다. 또한 이 문서는 시간 문제와도 마주합니다. 어떤 이름이 퍼블릭 서픽스로 분류되지 않았을 때 수용된 쿠키가, 목록이 바뀐 뒤에는 부적격해질 수 있다는 것입니다.

이것은 관측 가능한 결과를 갖는 거버넌스입니다. 데이터 파일의 한 줄이 브라우저가 상태를 수용·반환·보류하는지에 영향을 줄 수 있습니다. 그 결과는 상징적이지도, 법과 동등하지도 않습니다. 코드가 실행하는 제품 결정입니다. 표준은 규칙과 보안 근거를 공급하고, 목록은 현재의 경계 데이터를 공급하고, 브라우저나 라이브러리는 집행을 공급하며, 사이트 운영자는 쿠키를 공급합니다. 각 주체는 서로 다른 단계를 통제합니다.

이 분업은 두 가지 과장된 서술을 막는 데 도움이 됩니다. 첫째는 PSL 관리자가 “도메인을 통제한다”는 주장입니다. 그들은 DNS 위임, 등록, 권위 있는 확인을 통제하지 않습니다. 둘째는 목록이 단순 문서에 불과하다는 주장입니다. 쿠키, same-site, 인터페이스, 메일, 인증서 로직에서 널리 배포된 애플리케이션이 사용할 때 그것은 문서 이상입니다. 그 실질적 힘은 두 주장 사이에 있습니다. 다운스트림 소프트웨어가 채택하고 배포할 때만 항목이 결과를 낳는 조정 기록이라는 점입니다.

같은 패턴이 쿠키 밖에서도 나타납니다. ICANN의 최고기술책임자 사무국은 브라우저 프로세스·스크립트 경계, 도메인 해석, 인터페이스 강조, DMARC 조직 도메인 탐지 등에서의 사용을 문서화했습니다. 공개 PSL 사이트는 슈퍼쿠키 방지, 주소 표시줄 강조, 방문 기록 정렬을 원래 목적으로 나열합니다. 라이브러리들은 또 다른 판단에 이 데이터를 사용합니다. 이 용도들은 관련은 있지만 동일하지 않습니다. 쿠키 격리에 적합한 경계가 기업 신원, 메일 정책, 인증서 제한, 분석, 속도 제한에는 근사치에 불과할 수 있습니다.

그래서 하나의 목록을 조직적 진실의 완전한 지도라고 부르는 것은 적절하지 않습니다. 그것은 명시된 용도에 대한 유용한 추정을 기록할 뿐입니다. 모든 소비자는 그 추정이 자신의 판단에도 안전한지 스스로 증명할 책임이 있습니다.

ICANN 섹션과 사영 섹션은 서로 다른 근거를 설명한다

PSL 파일에는 두 개의 주요 섹션이 있습니다. “ICANN”으로 표시된 섹션은 IANA 루트와 그 아래 레지스트리 정책에 묶인 이름을 다룹니다. 사영 섹션은 보유자가 상호 신뢰하지 않는 주체들에게 서브도메인을 제공하는 도메인, 즉 최상위 위임으로 나타나지 않는 호스팅·플랫폼 패턴을 다룹니다.

“ICANN”이라는 표기는 소유로 읽으면 오해를 낳습니다. PSL 형식 문서 자체가 “IANA”가 더 정확했을 수 있으나 변경하면 통합이 깨질 수 있다고 적습니다. ICANN의 기술 가이드가 더 분명합니다. PSL은 Mozilla의 발의로 시작했으며, ICANN, IANA 기능, IETF의 직접 관리나 통제 밖에서 외부 자원봉사자들이 관리한다는 것입니다. 이 목록은 유일 루트 모델을 따르고 그 기관들의 권위 자료를 사용하지만, 근거 의존은 기관적 종속이 아닙니다.

Mozilla는 여기서 두 가지 제한된 역할의 기관 주체입니다. 발의의 출시자이자, Firefox를 통해 결과를 낳는 다운스트림 구현자 중 하나입니다. 이 글은 공유 기록이 실행 코드가 될 때 그 역할이 만드는 책임을 살펴봅니다. 그러나 그것이 Mozilla를 커뮤니티 목록의 현재 소유자로 만들거나 다른 소비자에 대한 권한을 주지는 않습니다.

사영 섹션은 이 분리를 더욱 분명하게 합니다. 플랫폼 운영자는github.io같은 도메인을 통제하면서 서로 신뢰하지 않는 다수에게 서브도메인을 제공할 수 있습니다. DNS는 플랫폼의 상위 도메인 통제를 정확히 보여 줍니다. 그래도 애플리케이션은 테넌트 격리가 한 레이블 아래에서 이루어져야 한다는 것을 알아야 합니다. 사영 섹션 등재는 운영자의 배치·보안 모델을 표현할 뿐, 상위가 최상위 도메인이라고 가장하지 않습니다.

이것은 얇은 공통 형식 안에서의 국소적 판단의 유용한 예입니다. 공통 규칙은 항목 표현 방식, 최장 일치와 예외 규칙의 작동 방식을 정합니다. 도메인 보유자는 공유 네임스페이스를 운영한다는 국소적 사실을 공급합니다. 관리자는 그 주장을 인증하고 요청이 목록의 목적에 부합하는지 검토합니다. 소비자는 사영 섹션 포함 여부와 부착할 용도를 자발적으로 결정합니다.

이 배치가 레지스트리와 닮은 것은 가장 좁은 의미에서뿐입니다. 경계 취급에 대한 고유하고 기계 판독 가능한 주장을 기록하기 때문입니다. 그것을 주권으로 확대해서는 안 됩니다. 관리자는 상호 신뢰하지 않는 사용자가 서브도메인을 받는지 판단하기 위해 플랫폼의 가격, 콘텐츠 규칙, 고객 자격, 상업 모델에 대한 권한을 필요로 하지 않습니다. 요청된 경계 진술이 진정하고 정확하며 목록에 적합한지 판단할 만큼의 근거만 필요로 합니다.

참여는 열려 있지만 수용은 여전히 통제된 행위다

누구나 풀 리퀘스트를 열 수 있습니다. 덕분에 관리 기록은 검사 가능해지고 외부인이 오류를 지적할 수 있습니다. 그러나 모든 참여자가 배포되는 목록을 바꿀 동등한 권한을 갖는다는 뜻은 아닙니다. 변경은 관리자가 형식·목적·인증 규칙을 적용한 뒤에야 수용됩니다.

현재 가이드라인은 요청자가 변경을 설명하고, 올바른 위치에 놓고, 예상 동작을 제시하며, 권한을 입증하도록 요구합니다. ICANN 섹션 변경에는 권위 있는 레지스트리 자료나 해당 관리자의 확인이 중요합니다. 사영 항목에는 도메인 보유자의 권한 있는 대표가 필요합니다. 가이드는 도메인을 풀 리퀘스트 번호에 연결하는 DNS TXT 레코드에 특별한 무게를 둡니다. 일부 민감한 네임스페이스에는 추가 검토가 이루어질 수 있습니다.

이것은 참석과 위임 사이의 중요한 구분입니다. 공개 의견은 결정을 개선할 수 있습니다. 기여자는 사실을 공급하거나 오류를 지적하거나 가정에 이의를 제기할 수 있습니다. 그것만으로는 도메인 보유자를 대변할 권한이 입증되지 않습니다. 인증은 더 좁은 질문에 답합니다. 요청자가 운영 경계가 기술되는 이름을 통제하거나, 그 통제 주체로부터 권한을 받았는가?

절차는 공개하다고 해서 완전하지는 않습니다. 저장소는 자원봉사 역량이 얇고, 고객 지원 조직이 없으며, 잘못된 형식의 항목이 쿠키를 파괴할 수 있다고 경고합니다.

2026년 5월 6일 고지는 표준화된 요청 양식을 요구하며, 그 확인 진술이 공개적이고 일관된 검토 기록의 일부임을 설명합니다.2025년 5월 27일 고지는 무관한 Cloudflare 제품 제한의 우회 수단으로 PSL을 사용하려는 시도를 거부합니다. 이 고지들은 활발한 경계 방어를 보여 줍니다. 관리자들이 보안 조정 목록이 플랫폼 기능, 광고 규칙, 인증서 제한을 위한 범용 자격 시스템이 되지 않도록 하려는 것입니다.

이 절제는 건강합니다. 등재가 부수 이익을 낳으면 목록은 사명 확장에 취약해집니다. 광고 시스템, 인증 기관, 분석 도구, 클라우드 제품이 자신의 제한에 PSL을 사용하는 순간, 신청자들은 테넌트 격리와 무관한 이유로 등재를 추구할 유인을 갖습니다. 관리자는 그러면 목록이 원래 해결하도록 설계되지 않은 상업적 주장을 판정하라는 압력에 직면합니다.

올바른 대응은 그런 외부 효과가 없다고 가장하는 것이 아니라 분리하는 것입니다. 요청자는 경계가 PSL의 공표된 목적에 부합함을 입증해야 합니다. 다운스트림 공급자는 PSL 상태에 붙인 제품 규칙을 스스로 정당화해야 합니다. 클라우드 공급자가 특정 기능을 등재된 서픽스에만 제공한다면, 그 자격 규칙의 책임은 공급자에게 남습니다. PSL은 공급자의 상업 설계를 수리하기 위해 수용 기준을 왜곡해서는 안 됩니다.

변경 인증이 모든 다운스트림 결과를 증명하지는 않는다

DNS TXT 레코드는 논의 중인 이름 아래에 놓이기 때문에 강력한 증거입니다. 풀 리퀘스트를 해당 존의 통제와 연결할 수 있습니다. 그러나 모든 서브도메인이 무관한 주체에 할당되어 있음, 요청자의 사업 모델이 안정적으로 유지될 것임, 모든 소프트웨어 소비자가 항목을 동일하게 해석해야 함은 증명하지 않습니다.

그래서 문서화와 운영 예시가 중요합니다. 사영 도메인 신청자는 누가 서브도메인을 받는지, 테넌트들이 상호 신뢰하지 않는지, 어떤 쿠키·same-site 취급이 따라야 하는지, 서비스가 닫히거나 할당 모델이 바뀔 때 무슨 일이 일어날지 설명해야 합니다. 레지스트리 섹션 변경은 2단계·3단계 레이블을 등록 경계로 만드는 권위 있는 정책을 밝혀야 합니다. 그러면 관리자는 기업 전체를 감사한다고 가장하지 않고 목록의 질문을 판단할 수 있습니다.

이 증거 규율은 삭제에도 적용되어야 합니다. 낡은 사영 항목은 플랫폼이 독립 테넌시를 더 이상 제공하지 않아도 이름을 격리 상태로 두는 수 있습니다. 너무 일찍 삭제하면 기존 계정, 리디렉션, 쿠키가 남아 있는 동안 사용자들이 공유 사이트 경계로 무너질 수 있습니다. 이 결정에는 관측 가능한 퇴역 이야기가 필요합니다. 도메인 통제, 테넌트 상태, 남은 사용자, 지원 클라이언트, 예정된 날짜, 롤백 한계입니다.

공개 저장소는 사영 공급자 기록 시스템과 비교할 때 비상하게 좋은 결정 기록을 제공합니다. 풀 리퀘스트, 검토 의견, 커밋은 누가 요청했고 어떤 근거가 공급되었으며 무엇이 병합되었는지 보여 줄 수 있습니다. 그러나 공개 기록은 원천 결정일 뿐입니다. 그것이 어디서 언제 효력을 발생했는지는 확립하지 않습니다. 그것에는 두 번째 장부, 즉 다운스트림 채택이 필요합니다.

출처

1. Lu Heng, “Running-Code Primacy: The Patch Needed to Preserve the Internet’s Original Design”
2. 퍼블릭 서픽스 리스트 프로젝트 개요
3. 퍼블릭 서픽스 리스트 소스 저장소와 현재 관리자 고지
4. 퍼블릭 서픽스 리스트 제출·검증 가이드라인
5. 퍼블릭 서픽스 리스트 파일 형식과 섹션 의미
6. ICANN OCTO-011, “The Public Suffix List: A Guide for TLD Administrators”
7. RFC 6265, HTTP 상태 관리 메커니즘
8. IETF HTTPbis 초안, Cookies: HTTP State Management Mechanism
9. WHATWG URL 표준
10. IETF DBOUND 워킹그룹 차터
11. RFC 8499, DNS 용어
12. Firefox 소스effective_tld_names.dat스냅샷
13. 2026년 5월 6일 퍼블릭 서픽스 리스트 관리자 고지: 표준화된 요청 양식과 확인 진술
14. 2025년 5월 27일 퍼블릭 서픽스 리스트 관리자 고지: Cloudflare 제한은 목록의 목적 밖