IETF가 DNS 위임 관리와 DNSSEC 운영에 관한 RFC 3건을 발행했습니다. 발표일은 모두 2025-09-01입니다. RFC 9859는 DNS NOTIFY를 영역 전송 말고 다른 용도에도 쓸 수 있게 넓히고, 알림 받을 곳을 찾는 DSYNC 레코드를 새로 정의합니다. RFC 9874(BCP 244)는 확장 가능 프로비저닝 프로토콜(EPP)에서 도메인 객체와 호스트 객체를 삭제할 때 DNS 해석 장애와 하이재킹 위험을 줄이는 방법을 다룹니다. RFC 9824는 DNSSEC 온라인 서명 환경에서 존재하지 않는 이름에 대한 응답을 더 작고 안전하게 만드는 간결한 부재 증명(Compact Denial of Existence) 기법을 정의합니다.
한눈에 보기
| RFC 번호 | 제목 | 종류 | 대체·갱신하는 RFC | 적용 대상 |
|---|---|---|---|---|
| RFC 9859 | Generalized DNS Notifications (일반화된 DNS 알림) | 표준 제안(Proposed Standard) | 원문에 없음 | 자식 영역 운영자, 부모 영역 운영자, 레지스트리·레지스트라 |
| RFC 9874 (BCP 244) | Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP) (EPP 도메인·호스트 객체 삭제 모범 사례) | 현행 모범 사례(BCP) | 원문에 없음 | 레지스트리(EPP 서버), 레지스트라(EPP 클라이언트) |
| RFC 9824 | Compact Denial of Existence in DNSSEC (DNSSEC의 간결한 부재 증명) | 표준 제안(Proposed Standard) | RFC 4034, RFC 4035 갱신 | 권한 서버(온라인 서명), 리졸버 |
건별 내용
RFC 9859: 일반화된 DNS 알림
기존 DNS NOTIFY(RFC 1996)는 주 서버가 보조 서버에 영역이 바뀌었다고 알려 영역 전송을 앞당기는 용도로만 쓰였습니다. 이 문서는 NOTIFY를 넓혀서 그동안 계기를 줄 수단이 없던 작업, 특히 부모 영역의 NS·DS 레코드 갱신 같은 위임 관리(delegation maintenance)를 DNS로 촉발할 수 있게 합니다. 알림은 정해진 작업을 주기를 기다리지 않고 바로 시작하라고 재촉할 뿐이며, 작업 내용이나 그 안의 보안 검사는 바꾸지 않습니다. 부모 운영자는 알림 받는 주소를 새 레코드 타입인 DSYNC에 자식 이름별로 게시하고(와일드카드로 일괄 지정도 가능), 지원하는 RRtype 값은 현재 CDS와 CSYNC뿐입니다. 원문은 이 문서로 DNS 프로토콜이 바뀌는 것은 없다고 밝힙니다.
RFC 9874: EPP 도메인·호스트 객체 삭제 모범 사례
RFC 5731과 RFC 5732는 하위 호스트 객체가 연결된 도메인 객체와 다른 객체에 연결된 호스트 객체를 삭제하지 말라고(SHOULD NOT) 권고합니다. 그래서 일부 레지스트라는 도메인을 지우려고 네임서버 호스트 객체의 이름을 외부 호스트(external host)로 바꾸는 방식을 써 왔습니다. 원문에 따르면, 바뀐 이름이 등록되지 않은 도메인을 가리키면 공격자가 그 도메인을 등록해 DNS 해석을 가로챌 수 있습니다. 또 권한 DNS 서비스를 가리키면 계정 탈취(하이재킹)가, 재귀 서비스를 가리키거나 DNS 서비스가 없으면 SERVFAIL과 불필요한 재질의가 생길 수 있습니다. 이 문서는 이런 관행의 위험을 분석하고, DNS 해석 실패 위험을 줄이면서 클라이언트와 서버의 데이터 일관성을 지키는 현행 모범 사례와 새로 제안하는 방법을 정리합니다.
RFC 9824: DNSSEC의 간결한 부재 증명
보통은 존재하지 않는 이름을 증명하려면 서명된 NSEC 레코드가 최대 2개, NSEC3 레코드는 최대 3개 필요합니다. 이 기법은 해당 이름이 "존재하지만 질의한 타입의 데이터는 없다"는 NODATA 응답을 그때그때 만들어서, 이름과 일치하는 NSEC 또는 NSEC3 레코드 하나만으로 응답합니다. 그 결과 응답 크기와 온라인 서명 연산이 줄고, NSEC 체인 탐색(zone walking)이나 NSEC3 해시 사전 공격으로 영역 내용이 드러나는 것도 막습니다. 존재하지 않는 이름과 빈 비종단 이름(ENT)을 구별할 수 있도록 메타 타입 NXNAME(128)을 정의하고, 이 타입을 NSEC Type Bit Maps에 넣게 합니다. 리졸버에는 특별한 처리가 필요 없습니다. 다만 NXDOMAIN을 애플리케이션에 되돌려 주는 동작(Signaled Response Code Restoration)을 선택적으로 구현할 수 있습니다.
운영·설계에 반영할 점
- 위임 갱신 자동화(RFC 9859): CDS·CDNSKEY·CSYNC로 DS·NS 갱신을 자동화하고 있거나 검토 중이라면, 부모 쪽에 DSYNC 레코드가 게시돼 있는지 확인하세요. 게시돼 있다면 NOTIFY를 보내 반영을 앞당길 수 있습니다. 알림은 부모의 기존 검사 절차를 대신하지 않으므로, CDS·CSYNC 레코드 자체의 정확성 관리는 그대로 필요합니다.
- 도메인 삭제 절차 점검(RFC 9874): 레지스트리·레지스트라 업무와 관련이 있다면, 도메인을 지울 때 호스트 객체 이름을 외부 이름으로 바꾸는 관행이 있는지, 바뀐 이름이 등록되지 않은 도메인이나 남의 DNS 서비스를 가리키지 않는지 점검하세요. 원문은 외부 호스트 이름으로 바꾸면 EPP 클라이언트가 되돌릴 수 없다고 밝힙니다.
- 위임 상태 모니터링: RFC 9874가 설명하는 위험은 위임 대상 네임서버가 엉뚱한 이름을 가리킬 때 생깁니다. 관리하는 영역의 NS 레코드가 실제로 운영 중인 서버를 가리키는지 주기적으로 확인하는 것이 좋습니다.
- NXDOMAIN 해석 방식 변화(RFC 9824): 이 기법을 쓰는 영역은 존재하지 않는 이름에 NXDOMAIN 대신 NOERROR/NODATA로 응답합니다. 응답 코드(RCODE)로 존재하지 않는 이름을 집계하는 로그 분석·모니터링·보안 탐지 규칙이 있다면, NXNAME 타입 비트를 함께 확인하도록 고칠 필요가 있는지 검토하세요.
- 온라인 서명 설계(RFC 9824): 응답을 그때그때 서명하는 권한 서버를 운영하거나 도입할 계획이라면, 응답 크기와 서명 연산을 줄이고 영역 내용 노출을 막는 방안으로 이 기법을 검토할 수 있습니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.