2024년 4월 26일 IETF가 DNS와 도메인 등록 데이터에 관한 제안 표준(Proposed Standard) 2건을 발행했습니다. RFC 9567은 검증 리졸버(validating resolver)가 이름 해석이나 DNSSEC 검증에 실패하면 이를 권한 서버(authoritative server) 운영자가 지정한 곳으로 자동 보고하는 방법을 정의합니다. RFC 9560은 등록 데이터 접근 프로토콜(Registration Data Access Protocol, RDAP)에 OpenID Connect 기반 연합 인증(federated authentication)을 적용하는 방법을 정의합니다.
한눈에 보기
| RFC 번호 | 제목 | 종류 | 대체·갱신하는 RFC | 적용 대상 |
|---|---|---|---|---|
| RFC 9567 | DNS Error Reporting (DNS 오류 보고) | 제안 표준(Proposed Standard) | 원문에 없음 | 권한 서버, 검증 리졸버, 모니터링 에이전트 |
| RFC 9560 | Federated Authentication for the Registration Data Access Protocol (RDAP) Using OpenID Connect (OpenID Connect를 이용한 RDAP 연합 인증) | 제안 표준(Proposed Standard) | 원문에 없음 | RDAP 서버·클라이언트(도메인 이름 레지스트리, 지역 인터넷 레지스트리) |
건별 내용
RFC 9567: DNS 오류 보고(DNS Error Reporting)
서명이 만료된 영역을 계속 서비스하거나 상위 영역의 위임 서명자(Delegation Signer, DS) 레코드가 하위 영역의 키 서명 키(KSK)와 맞지 않으면 검증 리졸버에서 검증이 실패합니다. 그런데도 권한 서버 운영자는 이를 한동안 모를 수 있습니다. 이 문서는 이런 실패를 RFC 8914의 확장 DNS 오류(Extended DNS Errors, EDE) 코드로 자동 보고하는 가벼운 방법을 정의합니다. 권한 서버는 응답에 EDNS0 Report-Channel 옵션(OPTION-CODE 18)을 요청이 없어도 넣어 보고받을 에이전트 도메인(agent domain)을 알립니다. 에이전트 도메인이 비어 있거나 루트(null label)이면 이 옵션을 넣으면 안 됩니다(MUST NOT). 이 기능을 지원하는 리졸버는 _er 레이블, QTYPE, 실패한 QNAME, 확장 DNS 오류 코드, _er 레이블, 에이전트 도메인을 차례로 이어 붙여 QNAME을 만들고, 이 이름으로 모니터링 에이전트(monitoring agent)에 TXT 질의를 보냅니다. 질의를 보내는 것 자체가 오류 보고가 됩니다.
RFC 9560: OpenID Connect를 이용한 RDAP 연합 인증
RDAP는 도메인 이름 레지스트리와 지역 인터넷 레지스트리의 등록 정보를 RESTful 웹 서비스로 조회하는 프로토콜입니다. 서버는 클라이언트의 신원에 따라 접근을 제어할 수 있습니다. 하지만 이용자가 수많은 서버 운영자마다 따로 계정을 받아 관리하는 방식은 규모가 커지면 감당하기 어렵고, 세밀한 접근 제어에 필요한 이용자 정보도 충분히 얻을 수 없습니다. 이 문서는 RDAP 서버가 식별과 인증을 신뢰할 수 있는 신원 제공자(identity provider)에게 맡기는 OpenID Connect 기반 연합 인증 체계를 정의합니다. 이용자가 동의하면 추가 신원 정보가 서버 운영자에게 전달되고, 서버 운영자는 질의의 성격과 함께 이 정보를 근거로 접근 수준을 정할 수 있습니다.
운영·설계에 반영할 점
- 권한 서버 운영자: DNS 오류 보고를 받으려면 보고를 받을 에이전트 도메인과 그 도메인의 권한 서버, 곧 모니터링 에이전트를 따로 마련해야 합니다. 들어오는 보고 질의(
_er레이블로 시작하는 TXT 질의)를 기록하고 분석하는 절차도 함께 설계해야 합니다. DNSSEC 서명 만료나 DS 불일치처럼 이용자 신고에 기대던 장애를 더 일찍 알아차리는 데 쓸 수 있습니다. - 리졸버 운영자: 원문에 따르면 리졸버는 이 기능을 쓰도록 설정된 경우에만 보고합니다. 보고하는 부담은 리졸버가 지므로, 기능을 켜기 전에 추가 질의가 본래 기능에 주는 영향을 검토하는 것이 좋습니다.
- 소프트웨어 지원 여부: 원문에는 구현 현황이 나오지 않습니다. 사용 중인 권한 서버·리졸버 소프트웨어가 EDNS0 Report-Channel 옵션과 보고 질의를 지원하는지는 각 제품의 문서와 릴리스 노트에서 확인하십시오.
- 레지스트리·RDAP 운영자: RDAP 서비스에 인증 기반 차등 접근을 도입하려면 RFC 9560의 OpenID Connect 연합 인증을 검토할 수 있습니다. 신뢰할 신원 제공자 선정, 이용자 동의를 받아 전달되는 정보의 범위, 접근 수준별 정책을 함께 설계해야 합니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.