IETF가 2023년 11월 6일 표준 트랙(Proposed Standard) RFC 5건을 함께 발행했습니다. 중심은 RFC 9460으로, 서비스 접속 정보를 DNS로 알려 주는 SVCB(Service Binding)와 HTTPS 리소스 레코드(RR)를 정의합니다. 나머지 4건은 이 레코드를 바탕으로 DNS 서버의 암호화 전송 지원을 알리는 방법(RFC 9461), 리졸버가 자기 대신 쓸 암호화 리졸버를 지정하는 방법(RFC 9462), DHCP·IPv6 라우터 광고(RA)로 암호화 리졸버를 알리는 방법(RFC 9463), IKEv2 VPN으로 암호화 리졸버를 할당하는 방법(RFC 9464)을 다룹니다. 여기서 암호화 DNS는 DNS over HTTPS(DoH), DNS over TLS(DoT), DNS over QUIC(DoQ)를 말합니다.
한눈에 보기
| RFC 번호 | 제목 | 종류 | 대체·갱신하는 RFC | 적용 대상 |
|---|---|---|---|---|
| RFC 9460 | Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) | 표준(Proposed Standard) | 원문에 없음 | 권한 서버(영역 운영) / DNS 클라이언트(HTTP 클라이언트 등) |
| RFC 9464 | Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS | 표준(Proposed Standard) | 원문에 없음 | IKEv2 VPN 장비·클라이언트 / 암호화 DNS 리졸버 |
| RFC 9463 | DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) | 표준(Proposed Standard) | 원문에 없음 | DHCPv4·DHCPv6 서버 / IPv6 라우터 / 호스트 / 암호화 DNS 리졸버 |
| RFC 9462 | Discovery of Designated Resolvers | 표준(Proposed Standard) | 원문에 없음 | 리졸버 / DNS 클라이언트 |
| RFC 9461 | Service Binding Mapping for DNS Servers | 표준(Proposed Standard) | 원문에 없음 | DNS 서버(리졸버 등) / DNS 클라이언트 |
건별 내용
RFC 9460: SVCB 및 HTTPS 리소스 레코드
SVCB와 HTTPS 레코드는 클라이언트가 서비스에 접속하는 데 필요한 정보, 곧 대체 엔드포인트와 엔드포인트별 매개변수(전송 프로토콜 설정 등)를 DNS 조회 한 번으로 알려 줍니다. 별칭 모드(AliasMode)는 운영 권한을 다른 이름에 위임하고, 서비스 모드(ServiceMode)는 엔드포인트의 설정 정보를 key=value 매개변수로 묶어 제공합니다. CNAME으로는 불가능했던 영역 정점(zone apex) 별칭도 지원합니다. HTTPS RR은 HTTP용 변형으로, HTTP/3 직접 접속, 기본값이 아닌 포트, HSTS와 비슷한 "https" 사용 신호, 암호화된 ClientHello(ECH) 키 전달 등을 목표로 합니다.
RFC 9464: 암호화 DNS를 위한 IKEv2 구성
IKEv2 구성 페이로드(Configuration Payload) 속성 유형을 새로 정의해, VPN 접속 단말(initiator)에 암호화 DNS 리졸버를 할당합니다. ENCDNS_IP4(27)와 ENCDNS_IP6(28)는 인증 도메인 이름(ADN, Authentication Domain Name), IP 주소 목록, 서비스 매개변수(SvcParams)를 전달하고, ENCDNS_DIGEST_INFO로는 특정 리졸버 인증서를 지정할 수 있습니다. 원문은 암호화 DNS를 쓰면 리졸버를 보호 영역 밖에 둘 수도 있지만, 기존 VPN 클라이언트 구현은 리졸버 IP가 터널 범위 밖에 있는 경우를 예상하지 못할 수 있다고 지적합니다.
RFC 9463: 네트워크 지정 리졸버 발견(DNR)
DHCPv4, DHCPv6, IPv6 라우터 광고(RA) 옵션으로 로컬 네트워크의 암호화 DNS 리졸버를 호스트에 알리는 방법을 정의합니다. 옵션에는 ADN, IP 주소 목록, 서비스 매개변수가 담깁니다. 공개키 기반 구조(PKIX) 인증서로 리졸버를 인증할 수 있도록 옵션에는 항상 ADN이 들어가고, ADN을 풀기 위해 다른 리졸버에 의존하지 않도록 IP 주소도 함께 전달합니다. 리졸버 선택 기준과 정책은 범위 밖입니다.
RFC 9462: 지정 리졸버 발견(DDR)
DHCP·RA·수동 설정처럼 리졸버의 IP 주소만 아는 상황에서도, 클라이언트가 DNS 조회로 그 리졸버의 암호화 DNS 설정을 찾아 암호화 DNS로 옮겨 갈 수 있게 합니다. IP 주소만 알면 특수 용도 도메인 이름(SUDN)을 조회하고, 암호화 리졸버의 호스트 이름을 알면 해당 이름의 SVCB 레코드를 조회합니다. 이렇게 찾은 리졸버는 같은 운영 주체이거나 협력하는 주체가 운영하는 경우로 제한됩니다. 원래 리졸버가 이 리졸버를 지정했다는 사실은 같은 IP 주소로 접근할 수 있는지, 또는 인증서에 원래 리졸버의 IP 주소가 들어 있는지로 확인합니다.
RFC 9461: DNS 서버를 위한 서비스 바인딩 매핑
SVCB를 DNS 서비스에 쓰기 위한 "dns" 서비스 유형 매핑을 정의해, 이름으로 식별되는 DNS 서버가 DoT·DoH·DoQ 지원을 알릴 수 있게 합니다. 조회 이름은 포트 접두 명명(Port Prefix Naming)을 따릅니다. 예를 들어 dns1.example.com은 _dns.dns1.example.com을 조회하고, 기본값이 아닌 포트 9953을 쓰면 _9953._dns.dns1.example.com을 조회합니다. "alpn" 키가 없으면 클라이언트는 다른 SvcParam이 지원 프로토콜을 나타내지 않는 한 그 레코드를 호환되지 않는 것으로 처리해야 합니다(MUST). alpn에 HTTP 버전이 들어 있으면 DoH를 지원한다는 뜻이고, 이때 "dohpath" 키가 반드시 있어야 합니다(MUST).
운영·설계에 반영할 점
- 영역 운영: 영역 정점(apex)에 CNAME을 둘 수 없어 쓰던 우회 방식이 있다면, HTTPS 레코드의 별칭 모드로 바꿀 수 있는지 검토합니다. 사용하는 권한 서버, 영역 편집 도구, 프로비저닝 체계가 SVCB·HTTPS 레코드 유형을 처리하는지 먼저 확인해야 합니다.
- 암호화 DNS를 제공하는 리졸버 운영: SVCB 레코드로 지원 사실을 알리려면 RFC 9461의 이름 규칙(_dns 접두, 기본값이 아닌 포트는 추가 접두)을 따릅니다. alpn은 꼭 넣고, DoH를 알릴 때는 dohpath도 함께 넣습니다.
- DDR 적용: 클라이언트는 같은 IP 주소로 접근할 수 있는지 또는 인증서에 원래 리졸버의 IP 주소가 들어 있는지로 지정 관계를 확인합니다. 따라서 평문 리졸버와 암호화 리졸버의 주소 배치, 인증서 발급 계획을 함께 설계해야 합니다.
- DNR·IKEv2 배포: DHCP·RA·VPN으로 전달하는 ADN은 리졸버 인증서 검증의 기준이 됩니다. 전달하는 ADN과 리졸버 인증서가 일치하는지 확인합니다. VPN 환경에서 리졸버를 터널 범위 밖에 둘 계획이라면, 사용 중인 VPN 클라이언트가 그런 구성을 처리하는지 시험해 봐야 합니다.
- 조회 이름 고려: 클라이언트가 _dns 접두 이름이나 HTTPS 레코드를 조회하게 되므로, 내부 영역이나 필터링 정책이 이런 조회에 어떻게 응답하는지 확인해 둡니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.