IETF가 2024년 2월 28일 RFC 9539 "Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS"를 발표했습니다. 재귀 리졸버(recursive resolver)와 권한 서버(authoritative server)가 상대방과 사전 협의 없이 각자 판단으로 암호화 전송을 시도해, 수동적 네트워크 감시자(passive network monitor)로부터 DNS 질의 내용을 보호하는 방법을 다룹니다. 표준 트랙이 아닌 실험(Experimental) 문서입니다.
무엇이 발표되었나
RFC 9539는 D. K. Gillmor, J. Salazar, P. Hoffman이 편집했습니다. 재귀 서버에서 권한 서버로 가는 구간(recursive-to-authoritative hop)에 기회적 암호화 전송(opportunistic encrypted transport)을 더 쉽고 빠르게 도입하도록 하는 것이 목적입니다.
주요 내용은 다음과 같습니다.
- 일방적(unilateral) 도입: 다른 쪽과 따로 맞추지 않고 기회적 탐색(opportunistic probing)만으로 적용할 수 있는 방식을 다룹니다.
- 기회적 보안(opportunistic security, RFC 7435): 원래 평문으로 오가던 트래픽을 암호화하되, 더 강한 보안 방식을 방해하거나 약하게 만들지 않는다는 원칙을 따릅니다.
- 사용하는 전송 방식: TLS 기반 DNS(DoT, RFC 7858)와 QUIC 기반 DNS(DoQ, RFC 9250)를 쓰며, 서버 인증(authentication)은 하지 않습니다. HTTPS 기반 DNS(DoH, RFC 8484)는 이 용도에서 다루지 않는데, DoH 클라이언트가 URL 경로(path)를 알아야 하기 때문이라고 설명합니다.
- 부작용 최소화: 암호화 전송 탐색 때문에 대역폭이나 CPU·메모리를 지나치게 쓰거나, DNS 인프라가 증폭 공격(amplification attack)에 이용될 위험을 줄이는 데 중점을 둡니다.
- 향후 과제: 능동적 공격자(active attacker)를 막을 수 있는 미래 프로토콜의 방향을 부록 B에서 간단히 소개하지만, 이 문서에서 규정하지는 않습니다.
문서는 기대 효과로 세 가지를 듭니다. 재귀-권한 구간 질의를 수동적 공격자로부터 보호하는 것, 이 트래픽을 대규모로 암호화해 본 실제 경험을 쌓는 것, 그리고 앞으로 나올 더 강한 보호 방식으로 넘어가는 다리 역할입니다.
영향 범위
재귀 리졸버와 권한 서버를 운영하는 쪽 모두에 해당합니다. 다만 이 방식은 서버를 인증하지 않으므로 능동적 공격자는 막지 못한다고 문서에 분명히 적혀 있습니다. 대신 더 강력한 방어책보다 도입하기 쉽고 위험이 적다는 점을 장점으로 듭니다. 실험 문서이기 때문에 반드시 따라야 하는 표준 요건은 아니며, 검토와 실험적 구현, 평가를 위해 공개된 것입니다.
운영자가 할 일
- 지금 바로 바꿔야 할 설정은 없습니다. 재귀-권한 구간 암호화를 검토 중이라면 이 문서를 기준 자료로 참고할 수 있습니다.
- 사용 중인 DNS 소프트웨어가 재귀-권한 구간에서 DoT나 DoQ를 지원하는지, 지원한다면 이 문서의 방식을 따르는지 제품 문서로 확인하세요.
- 시험 삼아 적용할 때는 문서가 짚은 부작용, 곧 대역폭과 CPU·메모리 사용량, 증폭 공격 가능성을 함께 지켜보는 것이 좋습니다.
- 이 방식은 서버 인증 없이 수동적 도청만 막는다는 점을 감안해 보안 요구 수준을 판단하세요.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.