IETF가 2026년 3월 1일 DNS 관련 RFC 2건을 제안 표준(Proposed Standard)으로 발행했습니다. RFC 9953은 메모리와 전력이 제한된 사물인터넷(IoT) 기기가 제한 환경용 애플리케이션 프로토콜(CoAP)로 DNS 질의를 주고받는 방식(DNS over CoAP, DoC)을 정의합니다. RFC 9848은 TLS 암호화 ClientHello(Encrypted ClientHello, ECH)에 필요한 설정을 DNS의 SVCB·HTTPS 리소스 레코드(RR)로 배포하는 방법을 정의합니다. 두 문서 모두 DNS를 통해 암호화 통신을 지원한다는 점은 같지만, 영향을 받는 쪽은 다릅니다. RFC 9953은 리졸버 운영 쪽에, RFC 9848은 권한 영역(zone) 운영 쪽에 더 가깝습니다.
한눈에 보기
| RFC 번호 | 제목 | 종류 | 대체·갱신하는 RFC | 적용 대상 |
|---|---|---|---|---|
| RFC 9953 | DNS over CoAP (DoC) | 표준(Proposed Standard) | 원문에 없음 | DoC 서버(스텁·재귀 리졸버 또는 권한 서버 역할), IoT 기기의 DoC 클라이언트 |
| RFC 9848 | Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings | 표준(Proposed Standard) | 원문에 없음 | SVCB·HTTPS 레코드를 게시하는 권한 영역 운영자, TLS 서버 운영자, ECH 지원 클라이언트 |
건별 내용
RFC 9953: CoAP 기반 DNS(DoC)
일반 DNS 질의(OPCODE 0)의 질의·응답 한 쌍을 CoAP 메시지 교환 한 번으로 옮기는 프로토콜입니다. 메시지는 DTLS 1.2 이상, TLS 1.3 이상, 또는 제한 환경용 객체 보안(OSCORE)으로 보호할 수 있습니다. 메모리가 수 킬로바이트에 불과하고 링크 계층 프레임이 수백 바이트 수준인 IoT 기기를 대상으로 합니다. CoAP의 블록 단위 전송(block-wise transfer)으로 DNS over DTLS의 경로 MTU(Path MTU) 문제를 피하고, CoAP 프록시를 캐시 계층으로 쓸 수 있습니다. DoH와 달리 CoAP의 FETCH 메서드를 사용하므로, 질의를 본문에 그대로 담으면서도 GET처럼 응답을 캐시할 수 있습니다. DoC 서버는 스텁 리졸버나 재귀 리졸버로 동작합니다. 상위 DNS 인프라와는 UDP, DoH, DoQ 같은 다른 전송 방식으로 통신하며, 필요하면(MAY) DNSSEC 검증을 대신 맡을 수도 있습니다.
RFC 9848: SVCB·HTTPS 레코드를 이용한 ECH 부트스트래핑
클라이언트는 서버에 접속하기 전에 ECH 설정을 알고 있어야 합니다. 이 문서는 그 설정을 SVCB·HTTPS 레코드의 새 서비스 매개변수(SvcParam) "ech"로 전달하는 방법을 정의하고, 이를 ECH의 기본 부트스트랩 수단으로 삼습니다. 값은 ECHConfigList이며, 표시 형식(presentation format)에서는 Base 64로 쓰고 이스케이프 시퀀스를 넣어서는 안 됩니다(MUST NOT). 이 레코드를 게시하는 쪽은 TargetName의 모든 IP 주소가 해당 개인 키를 가진 서버이거나 공개 이름(public name)에 대한 권한을 가진 서버인지 확인해야 합니다(MUST). 그렇지 않으면 접속이 완전히 실패합니다. 또한 ECH를 지원하는 클라이언트는 SVCB 해석에 성공했고 모든 대체 엔드포인트에 "ech"가 있으면, 직접 접속으로 되돌아가는 대체 동작(fallback) 없이 SVCB에만 의존해 접속해야 합니다(MUST).
운영·설계에 반영할 점
- ECH 레코드 게시 전 서버 측 준비 확인: "ech" 매개변수가 든 SVCB·HTTPS 레코드를 게시하려면, TargetName이 가리키는 모든 IP 주소의 서버가 개인 키를 가지고 있는지(또는 공개 이름에 대한 권한이 있는지) 먼저 확인해야 합니다. 클라이언트가 직접 접속으로 되돌아가지 않으므로, 잘못 게시된 레코드는 곧바로 접속 장애가 됩니다.
- TLS 버전 호환성: 대상 서버는 ECH와 호환되는 버전(작성 시점 기준 TLS 1.3, DTLS 1.3, QUIC 버전 1)을 지원하는 것이 권고됩니다(SHOULD). 지원하지 않으면 접속을 시도할 때마다 재시도가 생겨 지연과 자원 낭비로 이어집니다.
- 레코드 값 형식: "ech" 값은 Base 64로 인코딩한 ECHConfigList이고 이스케이프 시퀀스를 넣을 수 없습니다. 영역 파일 작성 도구나 검증 절차에서 이 형식을 따르는지 점검하는 것이 좋습니다.
- ECH 키 교체와 DNS 갱신의 연동: ECH 설정이 DNS로 배포되므로, TLS 서버 쪽 설정을 바꿀 때는 DNS 레코드 갱신 절차와 함께 계획해야 합니다.
- IoT 환경의 리졸버 설계(RFC 9953): IoT 기기에 암호화된 이름 해석을 제공해야 한다면, DoC 서버를 기존 재귀 리졸버 앞에 두고 상위와는 UDP·DoH·DoQ로 통신하는 구성을 검토할 수 있습니다. 이때 DoC 서버가 DNSSEC 검증을 대신 맡을지, CoAP 프록시를 캐시 계층으로 둘지를 설계 단계에서 정해 두는 것이 좋습니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.