IETF가 2025-06-01 자로 DNS 관련 RFC 4건을 제안 표준(Proposed Standard)으로 발행했습니다. 멀티캐스트 없이 유니캐스트 DNS 업데이트(DNS Update)만으로 DNS 기반 서비스 발견(DNS-SD)을 쓸 수 있게 하는 서비스 등록 프로토콜(SRP, RFC 9665)과, 동적으로 추가된 레코드에 수명을 붙이는 업데이트 임대(Update Lease) EDNS(0) 옵션(RFC 9664)은 함께 읽어야 하는 문서입니다. 그 밖에 레지스트리에서 도메인 위임 레코드의 TTL(Time-to-Live)을 클라이언트가 관리할 수 있게 하는 확장 가능 프로비저닝 프로토콜(EPP) 확장(RFC 9803)과, ".onion" 특수용도 도메인 이름에 자동 인증서 관리 환경(ACME)으로 인증서를 발급하는 확장(RFC 9799)이 있습니다.
한눈에 보기
| RFC 번호 | 제목 | 종류 | 대체·갱신하는 RFC | 적용 대상 |
|---|---|---|---|---|
| RFC 9665 | DNS 기반 서비스 발견(DNS-SD)을 위한 서비스 등록 프로토콜(SRP) | 제안 표준 | 원문에 없음 | 권한 서버(SRP 등록기), DNS-SD로 서비스를 알리는 소프트웨어, DNS-SD가 필요한 네트워크 관리자 |
| RFC 9803 | DNS TTL 값을 위한 EPP 매핑 | 제안 표준 | 원문에 없음 | 레지스트리(EPP 서버), 레지스트라 등 EPP 클라이언트 |
| RFC 9799 | ".onion" 특수용도 도메인 이름을 위한 ACME 확장 | 제안 표준 | 원문에 없음 | ACME 서버(인증기관), ACME 클라이언트, Tor 어니언 서비스 운영자 |
| RFC 9664 | DNS 업데이트의 임대(Lease) 협상을 위한 EDNS(0) 옵션 | 제안 표준 | 원문에 없음 | DNS 업데이트 요청자, 권한 서버 |
건별 내용
RFC 9665: DNS-SD를 위한 서비스 등록 프로토콜(SRP)
SRP는 표준 DNS 업데이트(RFC 2136) 방식을 이용해 유니캐스트 패킷만으로 DNS-SD를 가능하게 합니다. 멀티캐스트 DNS(mDNS) 없이 배포할 수 있어 확장성이 좋아지고, 멀티캐스트가 적합하지 않은 IEEE 802.11(Wi-Fi)·IEEE 802.15.4 네트워크에서 성능이 개선된다고 원문은 설명합니다. SRP 등록기(SRP Update를 지원하는 권한 DNS 서버)는 기본 조건(predicate)을 적용해 업데이트를 통째로 성공시키거나 실패 이유를 알 수 있게 거부하며, "선착순 이름 지정(FCFS Naming)"으로 먼저 이름을 차지한 요청자의 SIG(0) 키를 갖지 않은 다른 요청자의 등록을 막습니다. 다만 여기서 "인증"은 같은 출처에서 온 업데이트임을 확인한다는 뜻일 뿐 신뢰를 확립한 것이 아니므로, 추가할 수 있는 레코드의 종류와 내용을 제한하고 있습니다.
RFC 9803: DNS TTL 값을 위한 EPP 매핑
도메인 위임 레코드(NS, DS, DNAME, 그리고 필요한 경우 네임서버의 A/AAAA)의 TTL은 보통 레지스트리 운영자가 정합니다. 이 문서는 EPP 도메인·호스트 객체 매핑(RFC 5731, RFC 5732)에 <ttl:ttl> 요소를 추가해, 해당 객체를 관리하는 클라이언트가 위임 레코드의 TTL을 바꿀 수 있게 합니다. 원문은 DNS 서버 교체, DNSSEC 도입이나 키 롤오버(key rollover)에 걸리는 시간을 줄이거나 빠르게 되돌리는 경우를 예로 듭니다. for 속성은 "NS", "DS", "DNAME", "A", "AAAA", "custom" 중 하나여야 하며, 서버는 응답에 설정 가능한 최솟값(min) 등을 알려줄 수 있습니다.
RFC 9799: ".onion" 특수용도 도메인 이름을 위한 ACME 확장
Tor 어니언 서비스(".onion" 특수용도 도메인 이름)에 ACME로 인증서를 자동 발급하기 위한 확장입니다. ".onion" 이름은 DNS의 일부가 아니므로 기존 "dns-01" 챌린지는 사용해서는 안 되며(MUST NOT), http-01과 tls-alpn-01은 이 문서의 수정 사항을 적용해 사용할 수 있습니다. 와일드카드 인증서 발급을 위해 특수 서명된 인증서 서명 요청(CSR)을 이용하는 새 챌린지 "onion-csr-01"을 정의하고, DNS 인증기관 권한(CAA) 레코드를 대신할 수단도 정의합니다. 버전 2 어니언 주소는 안전하지 않은 것으로 보아 사용을 금지합니다.
RFC 9664: DNS 업데이트의 임대 협상을 위한 EDNS(0) 옵션
DNS 업데이트로 추가된 레코드는 이동 단말이 네트워크를 떠나면 제대로 삭제되지 않고 권한 서버에 계속 남는 경우가 많습니다. 이 문서는 DNS 업데이트 요청과 응답에 임대 기간(초 단위)을 담는 업데이트 임대 EDNS(0) 옵션(OPTION-CODE UPDATE-LEASE (2))을 정의해, 갱신되지 않은 레코드를 서버가 정리(garbage collect)할 수 있게 합니다. 서버가 실제로 허용하는 임대 기간은 요청값보다 짧거나 길거나 같을 수 있습니다. 4바이트 형식은 모든 레코드에 하나의 임대 기간을, 8바이트 형식은 KEY 레코드에 별도 임대 기간(KEY-LEASE)을 적용하며, 이는 SRP(RFC 9665)에서 서비스가 없을 때에도 KEY 레코드로 이름을 예약해 두기 위한 것입니다.
운영·설계에 반영할 점
- SRP와 업데이트 임대는 함께 검토하세요. SRP 등록기를 운영하려면 RFC 9665와 RFC 9664를 같이 구현·검토해야 합니다. 동적 업데이트로 추가된 레코드의 수명, KEY 레코드에 따로 적용되는 임대 기간, 만료된 레코드 정리 정책을 미리 정해 두는 것이 좋습니다.
- SIG(0) 인증의 한계를 알고 쓰세요. SRP의 인증은 같은 요청자임을 확인할 뿐 요청자를 신뢰한다는 뜻이 아닙니다. SRP 업데이트를 받는 영역(zone)은 기존 운영 영역과 분리하고, 허용하는 레코드 종류를 원문에 정한 범위로 제한해야 합니다.
- 위임 TTL 조정 절차를 다시 보세요. 레지스트리가 RFC 9803을 지원하면 네임서버 교체나 DNSSEC 키 롤오버 전에 위임 레코드(NS·DS)의 TTL을 미리 낮추는 절차를 EPP로 처리할 수 있습니다. 레지스트리마다 허용하는 최솟값과 기본값이 다를 수 있으니 응답으로 받은 값을 확인해야 합니다.
- ".onion" 인증서는 DNS 검증 대상이 아닙니다. ".onion" 이름에는 dns-01 챌린지와 DNS CAA 레코드를 쓸 수 없습니다. 인증서 발급 자동화 체계에서 ".onion" 이름을 DNS 기반 검증 흐름에 넣지 않도록 해야 합니다.
- 4건 모두 대체·갱신하는 RFC는 이번에 받은 원문 발췌에서 확인할 수 없었습니다. 정확한 관계는 각 RFC 정보 페이지에서 확인하시기 바랍니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.