NSEC3는 당신의 DNS 존을 숨겨줄 거였다. 못 숨긴다.
이름이 존재하지 않음을 증명하는 DNSSEC의 장치가, 존재하는 이름 목록을 통째로 흘린다. NSEC3는 이름을 해시해 zone walking을 막으려 했지만 — 오프라인 크래킹이 그대로 뚫었다. RFC 9276이 왜 iterations를 0으로 두라고 하는지, 그리고 실제로 통하는 게 뭔지.
블로그
프로토콜, 보안 사건, 그리고 인터넷이 실제로 작동하는 방식. 147편.
.internal TLD, 10년 걸려서 나왔는데 절반짜리 해결책이다
ICANN이 2024년 7월 드디어 .internal을 사내망 전용으로 예약했다. .corp·.home을 괴롭히던 name collision 위험은 없앴지만, special-use domain이 아니라 그냥 '예약'이라 쿼리 유출은 여전히 당신 몫이다.
Public Suffix List: 쿠키가 어디까지 갈 수 있는지 정하는 파일
레지스트리가 끝나고 누군가의 웹사이트가 시작되는 지점을 DNS는 알려 주지 않는다. 그래서 웹 전체가 손으로 관리되는 텍스트 파일 하나에 그 경계를 맡긴다 — 쿠키, 인증서, 그리고 누가 누구를 사칭할 수 있는가까지.
DNS 0x20: 무작위 대문자로 쓰인 스푸핑 방어책
2023년 구글 리졸버는 조용히 wikipedia.org 대신 wIKiPEDiA.oRG를 묻기 시작했다. 버그가 아니다 — 표준이 되지 못한 채 15년을 버틴 스푸핑 방어 해킹이고, 그럼에도 작동하며, 그 누구의 허락도 필요 없어서 배포됐다.
DNS 쿠키: 아무도 켜지 않은 스푸핑 방어책
10여 년 전 DNS는 위조된 응답과 반사 공격을 막을 값싼 방어책을 얻었다. 당신의 리졸버는 거의 확실히 이걸 지원한다. 그리고 거의 확실히 요구하지는 않는다 — '지원'과 '요구' 사이의 그 틈이 이야기의 전부다.
KeyTrap: DNSSEC의 '모든 키를 시도하라'가 버그였다
2024년 2월, 조작된 DNS 패킷 하나가 검증 리졸버를 몇 시간 동안 얼릴 수 있었다. 결함은 코딩 실수가 아니라 1999년까지 뿌리가 거슬러 올라가는 DNSSEC 명세의 요구사항이었다.
루트 도메인엔 CNAME을 못 건다 (그 이유)
모든 CDN이 루트 도메인을 호스트명으로 향하게 하라고 한다. DNS는 1987년부터 바로 그걸 금지해 왔다 — 그래서 업계는 비표준 편법 더미를 쌓았고, 진짜 해결책은 아직 브라우저에서 안 먹는다.
QNAME 최소화: 실제로 배포된 DNS 프라이버시 개선
예전엔 당신과 사이트 사이의 모든 DNS 서버가 당신이 입력한 전체 이름을 봤다 — TLD만 알면 되는 서버까지도. 리졸버 쪽 변경 하나가 그 대부분을 고쳤고, DNSSEC과 달리 누구의 허락도 구하지 않고 배포됐다.
Encrypted Client Hello는 생각보다 덜 감춘다
ECH는 HTTPS가 늘 흘리던 단 하나의 필드 — 사이트 이름 — 를 드디어 암호화한다. 하지만 당신 IP, DNS 조회, 그리고 숨는 군중의 크기가 그게 의미 있는지를 결정한다.
Chrome은 DNS를 암호화했다. 검증한 적은 없다.
Chrome에서 보안 DNS를 켜면 리졸버로 가는 파이프가 암호화된다. 돌아온 답이 진짜라는 증명은 전혀 하지 않는다. 암호화와 인증은 다른 문제이고, 브라우저는 조용히 하나만 골랐다.
TLS 설정을 DNS로 옮겼다. 그런데 DNS는 서명이 안 돼 있다
HTTPS DNS 레코드는 핸드셰이크가 시작되기도 전에 브라우저에 연결 파라미터를 넘긴다 — 어떤 프로토콜, 어떤 IP, 심지어 ClientHello를 암호화할 키까지. 대부분의 도메인에서, 그건 아무도 서명하지 않은 계층으로 도착한다.
모든 DNS 제공자는 DNSSEC를 기본값으로 켜야 한다
DNSSEC의 진짜 문제는 암호학이 아니다. DNS 호스트와 등록대행자 사이의 2자 핸드셰이크를 거의 아무도 끝내지 않는다는 것이다. 자동화는 이미 이걸 해결했다.