이메일 포워딩은 왜 모든 걸 망가뜨리는가
SPF는 첫 relay에서 죽는다. DKIM은 메일링 리스트가 본문을 건드리는 순간 깨진다. 그리고 DMARC가 40년 된 골칫거리를 반송 메일로 바꿔놓는다. 이메일에서 가장 확실하게 고장 나는 기능 이야기.
블로그
프로토콜, 보안 사건, 그리고 인터넷이 실제로 작동하는 방식. 147편.
DNS TTL: 약속한 값 vs 리졸버가 실제로 하는 일
TTL을 300으로 잡고 5분이면 바뀌겠지 했는데, 한 시간이 지나도 트래픽이 옛 IP로 들어온다. TTL은 일정표가 아니다. 캐시들의 사슬에 건네는 힌트일 뿐이고, 그 캐시들은 저마다 당신을 무시할 권리를 갖고 있다.
DKIM Alignment: 다들 헷갈리는 바로 그 부분
DKIM 서명이 유효하다고 DMARC를 통과하는 게 아니다. 서명은 '어떤 도메인이 서명했다'만 증명한다. 그 도메인이 당신의 From 주소를 대변할 자격이 있는지는 alignment가 결정한다.
호모그래프 공격: 도메인 이름이 거짓말을 할 때
2017년, 한 연구자가 Chrome·Firefox·Opera 주소창에 apple.com으로 표시되는 도메인을 등록했다. 유효한 HTTPS 인증서까지 달려 있었다. 모든 글자가 키릴 문자였다. 이 문제가 고치기 어려운 이유는 버그 자체보다 더 오래되고 기묘하다.
당신의 브라우저는 왜 150개의 인증기관을 신뢰하는가
약 150개 인증기관 중 단 하나라도 당신 도메인의 유효한 인증서를 발급할 수 있다. 당신의 보안은 그중 가장 약한 곳의 수준이다. 그런데도 이게 대체로 굴러가는 이유.
우리는 UDP 위에 TCP를 다시 만들고 QUIC라고 불렀다
QUIC는 신뢰성이 있고, 순서를 보장하고, 혼잡 제어를 하고, 전부 암호화한다 — UDP가 한사코 하지 않으려는 모든 것이다. 그런데 왜 하필 UDP 위에 만들었을까? UDP가 인터넷 배관에 남은 유일한 '새 프로토콜 모양의 구멍'이었기 때문이다.
루트 서버가 13개라는 착각
다들 DNS 루트 서버가 13개라고 말한다. 실제로는 2,000개쯤 된다. 13이라는 숫자는 이제 아무도 신경 쓰지 않는 패킷 크기 제한 때문에 인터넷에 얼어붙어 있다 — 그리고 그 모순이 풀린 방식이야말로 지금껏 나온 인프라 꼼수 중 손꼽히게 좋은 것이다.
DNS는 왜 UDP를 쓰는가 (그리고 안 쓸 때는 언제인가)
DNS는 인터넷에서 가장 바쁜 요청-응답 시스템을, 패킷이 도착한다고 보장하지 않는 전송 위에 올려놨다. 꼼수가 아니었다. 옳은 선택이었다 — 답이 너무 커지기 전까지는.
서버는 당신이 봇이라는 걸 어떻게 아는가
User-Agent 문자열에는 아무 브라우저나 적어 넣을 수 있다. 그래서 아무도 그 필드를 믿지 않는다 — 그 아래에 깔린 TLS 핸드셰이크와 HTTP/2 설정은 당신이 아니라 당신이 쓴 라이브러리가 적은 것이기 때문이다.
CDN은 단일 장애점이다
CDN이 몇 곳으로 몰리면서 한 번의 장애가 수천 개 사이트를 동시에 내린다. 우리는 분산된 회복력을 중앙화된 편리함과 맞바꿨다.
DNS-over-HTTPS는 아무것도 안 바꿨다 (그리고 모든 걸 바꿨다)
DoH는 DNS 쿼리를 HTTPS로 감싼다. 같은 질문, 같은 답, 다른 전송. 기술 변화는 단순하다. 정치적 파장은 거대하다.
CDN 캐시 포이즈닝의 작동 원리
CDN 캐시 포이즈닝은 CDN을 속여서 악성 응답을 캐시하게 하고 모든 후속 방문자에게 서빙하게 한다. 이상한 요청 하나, 대량의 부수 피해.