사이트 차단은 어디서 일어날까 — DNS·SNI·CDN 통제점을 구분하는 법

warning.or.kr 안내 페이지, 아무 응답 없이 끝나는 흰 화면, 451 상태코드는 모두 "사이트가 막혔다"고 느끼게 한다. 하지만 같은 현상이 아니다. 어느 계층에서 연결을 멈췄는지, 다른 네트워크에서도 같은 결과가 나는지가 다르다.

이 차이를 지우면 진단도 틀어진다. DNS 응답 하나만 보고 SNI 차단이라고 단정하거나, CDN이 반환한 법적 제한 응답을 경로 중간 장비의 간섭으로 잘못 읽게 된다. 먼저 차단을 계층으로 나눠야 한다.

같은 차단처럼 보여도 관측 지점은 다섯 곳이다

OONI는 웹 차단을 IP 차단, DNS 간섭, HTTP 차단, SNI 필터링처럼 서로 다른 측정 범주로 나눈다.¹ 운영 관점에서는 서비스 종단 정책까지 더해 아래 다섯 층으로 보는 편이 유용하다.

warning.or.kr 안내가 보였다는 사실만으로 DNS 방식이라고 확정할 수는 없다. DNS가 차단 안내 주소를 돌려준 경우와 평문 HTTP의 Host·URL 필터가 안내 페이지로 보낸 경우를 DNS 패킷과 HTTP 응답으로 구분해야 한다.

DNS 변조라는 표현도 증거와 함께 써야 한다. 권위 DNS와 다른 응답이 나와도 재귀 리졸버의 정책 응답, 경로상 응답 주입, 캐시 문제, 실제 권위 레코드 변경은 서로 다른 원인이다. 서로 다른 네트워크와 리졸버에서 DNS 응답을 비교하고, TCP 연결과 TLS 핸드셰이크, 최종 HTTP 상태를 함께 남겨야 차단 계층을 좁힐 수 있다.

국내 차단은 DNS에서 SNI와 CDN으로 관측점을 옮겨 왔다

감사원 자료는 국내 해외 불법정보 차단 방식을 DNS 단계, 2008년부터의 URL 단계, 2019년 SNI 단계로 구분한다.² 이 연혁은 한 기술이 이전 기술을 완전히 없앤 교체사가 아니다. HTTPS 보급으로 평문 URL이 보이지 않자 집행 가능한 관측점을 옮기고, 사안과 사업자에 따라 여러 방식을 병행해 온 과정에 가깝다.

SNI 단계의 중요한 차이는 정밀도다. 평문 HTTP 필터는 /page/a 같은 경로를 볼 수 있지만 TLS SNI는 대개 호스트 이름까지만 구분한다. 같은 호스트에 적법한 페이지가 섞여 있어도 서비스 전체가 영향을 받을 수 있다. 2019년 KT 사례는 이 범위 차이와 목록 운영의 오차가 실제 과잉 적용으로 이어질 수 있음을 보여준다.

그리고 통제는 다시 종단으로 이동하고 있다. CDN이 국내 캐시에서 요청을 직접 처리하거나 TLS를 종료하면 경로 중간에서 읽지 못한 값도 종단은 안다. ECH가 CDN 통제를 없애지 못하는 이유는 SNI·ECH와 CDN 통제 지점에서 더 자세히 다뤘다.

DoT·DoH·ECH는 각각 다른 평문 단서를 줄인다

DoT(DNS over TLS)와 DoH(DNS over HTTPS)는 클라이언트와 재귀 리졸버 사이의 DNS 질의·응답을 암호화한다. DoT는 전용 TLS 전송을, DoH는 HTTPS 전송을 정의한다.⁹¹⁰ 둘 다 로컬 네트워크가 평문 질의 이름을 읽거나 응답을 바꾸기 어렵게 하지만, 선택한 리졸버는 질의 이름을 알고 응답 정책을 적용할 수 있다. DNSSEC는 응답 데이터의 출처와 무결성을 검증하는 기술이지 질의를 숨기는 기술이 아니다.

ECH(Encrypted Client Hello)는 TLS 1.3의 ClientHelloInner를 암호화해 실제 SNI와 ALPN 같은 값을 경로 관찰자에게서 감춘다. 2026년 3월 RFC 9849로 표준화됐다.¹¹ 실제 연결에는 네 조건이 함께 맞아야 한다.

1. 클라이언트가 ECH를 구현하고 활성화해야 한다.
2. DNS HTTPS 레코드가 유효한 ECHConfig를 전달해야 한다.
3. 클라이언트가 그 설정을 간섭 없이 얻어야 한다.
4. 서버·CDN이 ECH를 받아 복호화해야 한다.

이 조합은 평문 DNS나 SNI 하나에 의존한 경로형 분류의 전제를 바꾼다. 어떤 네트워크에서는 기존 방식이 같은 근거로 더 이상 성립하지 않는 결과가 생길 수 있다. 그러나 이를 보편적인 차단 해제 기능으로 부르면 틀리다. 목적지 IP, 연결 시각과 크기, 알려진 암호화 DNS 종단, CDN과 애플리케이션 정책은 남는다. 이란에서는 DoH로 이름을 조회해도 평문 SNI가 차단됐고, DoT·DoH 리졸버 종단 자체가 간섭 대상이 된 사례도 측정됐다.¹²

2026년 7월 지원 현황은 ‘제품명’보다 성립 조건으로 본다

"이 브라우저는 ECH를 지원한다"는 말만으로는 부족하다. 같은 제품도 버전, 배포 채널, 관리 정책, DNS 모드, 접속하는 사이트의 HTTPS 레코드와 CDN에 따라 실제 협상 결과가 달라진다. 공개 문서에서 확인되지 않는 항목은 미지원으로 단정하지 않고 확인 불가로 남겼다.

도구도 "지원"과 "검증 가능"을 구분해야 한다.

지원표는 제품 구매표보다 검증 계획으로 쓰는 편이 낫다. DNS HTTPS 레코드가 있는지, 클라이언트가 ECH를 제안했는지, 종단이 수락했는지, 실패하면 어느 DNS 경로와 TLS 형태로 돌아가는지를 실제 대상 환경에서 기록해야 한다.

해외 사례는 차단과 회피가 다음 계층으로 이동하는 과정을 보여준다

해외 사례에서 반복되는 패턴은 단순하다. 한 관측값이 암호화되면 필터는 다른 값이나 더 넓은 단위로 이동한다. 그럴수록 정밀도는 낮아지고 정상 서비스가 함께 영향을 받을 가능성은 커진다.

여기서 "회피"를 성공·실패의 이분법으로 읽으면 중요한 부분을 놓친다. 일부 패킷 변형이나 공유 인프라가 한동안 분류를 어렵게 만들 수 있지만, 필터는 IP·프로토콜 지문·속도 제한으로 이동할 수 있다. 반대로 넓은 차단은 정상 도메인과 핵심 인프라까지 손상시킨다. 결국 기술 경쟁은 가시성, 정밀도, 부수 피해, 플랫폼 정책 사이의 비용 배분이다.

운영자는 오류 화면보다 증거 묶음을 남겨야 한다

서비스 가용성과 컴플라이언스를 함께 다루려면 한 번의 접속 성공 여부보다 재현 가능한 증거가 필요하다.

1. DNS 답을 비교한다. 로컬 재귀 DNS, 승인된 암호화 DNS, 권위 DNS의 응답·TTL·확장 오류를 비교하되 차이를 곧바로 공격으로 단정하지 않는다.
2. 중단 단계를 기록한다. TCP 연결, ClientHello 이후 서버 응답, 인증서, HTTP 상태와 응답 표식을 순서대로 남긴다.
3. 망과 기기를 교차한다. 통신사, 사내망, 모바일망, 관리형 단말에 따라 결과가 달라지는지 본다.
4. 판단과 집행 주체를 분리한다. 규제기관 심의, ISP 구현, CDN Trust & Safety의 이의 절차는 서로 다르다.
5. 공유 인프라의 폭발 반경을 계산한다. 같은 IP·CDN 엣지·인증서 정책을 공유하는 정상 서비스가 함께 영향을 받는지 확인한다.
6. 암호화와 폴백을 운영 정책으로 만든다. DoH·DoT·ECH의 성공 여부뿐 아니라 실패 시 평문으로 낮아지는지, 연결을 중단하는지, 관리형 환경과 충돌하는지를 명시한다.

차단 여부를 판단하는 가장 좋은 질문은 "어떤 사이트가 열리는가"가 아니다. 누가 어떤 값을 보고 어디에서 결정을 내렸으며, 그 결정을 입증할 로그가 무엇인가다. 이 질문을 기준으로 잡으면 프라이버시 기술, 기업 보안, 법적 집행과 장애를 같은 네트워크 현상으로 뭉개지 않을 수 있다.

DNS·TLS·CDN 통제점과 폴백 경로를 서비스 아키텍처에 맞게 검증하는 일은 클라우드 & 인프라에서, 규제·가용성·운영 절차를 함께 설계하는 일은 AX 컨설팅에서 다룬다.

참고 자료

지원 현황은 공개 제품 문서를 기준으로 2026년 7월 16일 확인했다. 국가별 구현은 사업자와 시기에 따라 달라질 수 있으므로 개별 측정을 국가 전체의 고정 동작으로 일반화하지 않았다.