IETF가 DNS 운영과 관련된 RFC 3건을 발행했습니다. RFC 9718은 IANA가 루트 영역의 DNSSEC 신뢰 앵커(Trust Anchor)를 배포할 때 쓰는 형식과 게시 방법을 설명하며, RFC 7958을 대체합니다. RFC 9715는 UDP 기반 DNS에서 IP 단편화(IP Fragmentation)를 피하는 기법을 정리한 정보 문서입니다. RFC 9704는 스플릿 호라이즌(Split-Horizon) DNS 환경에서 도메인 소유자가 특정 하위 도메인에 권한 있는 응답을 할 수 있는 로컬 리졸버를 클라이언트에 알리는 방식을 정의한 표준 트랙 문서입니다.
한눈에 보기
| RFC 번호 | 제목 | 종류 | 대체·갱신하는 RFC | 적용 대상 |
|---|---|---|---|---|
| RFC 9718 | DNSSEC Trust Anchor Publication for the Root Zone (루트 영역의 DNSSEC 신뢰 앵커 게시) | 정보(Informational) | RFC 7958 대체 / 갱신 대상: 원문에 없음 | 신뢰 앵커를 설정하는 DNSSEC 검증 클라이언트·리졸버, 소프트웨어 공급사 |
| RFC 9715 | IP Fragmentation Avoidance in DNS over UDP (UDP 기반 DNS에서 IP 단편화 회피) | 정보(Informational) | 원문에 없음 | 공인 IP로 인터넷에서 운영되는 권한 서버와 리졸버 (사설·로컬 네트워크는 범위 밖) |
| RFC 9704 | Establishing Local DNS Authority in Validated Split-Horizon Environments (검증된 스플릿 호라이즌 환경에서 로컬 DNS 권한 확립) | 표준 제안(Proposed Standard) | 원문에 없음 | 도메인 소유자(공개 영역), 네트워크가 제공하는 하이브리드 리졸버, 하이브리드 DNS 클라이언트 |
건별 내용
RFC 9718: 루트 영역의 DNSSEC 신뢰 앵커 게시
DNSSEC 서명은 "신뢰 앵커"까지 서명 사슬을 따라가며 검증하므로, 루트 영역에서 검증된 응답을 받으려면 클라이언트에 알맞은 신뢰 앵커가 설정되어 있어야 합니다. 이 문서는 ICANN이 계열사 PTI(Public Technical Identifiers)를 통해 수행하는 IANA 기능으로서 루트 영역 신뢰 앵커를 배포하는 형식과 방법을 설명하고, RFC 7958을 대체합니다. 신뢰 앵커는 XML 문서로 게시되며, DS 레코드 표현 형식과 같은 DNSKEY 해시는 필수, DNSKEY 키와 플래그는 선택 항목입니다. 이 형식은 RFC 4033의 신뢰 앵커 정의와는 다르지만 위임 서명자(DS) 레코드로 변환할 수 있습니다. 또한 RFC 5011의 자동 신뢰 앵커 갱신을 대신하는 것이 아니라 보완하는 것이며, RFC 5011 방식이 출발점으로 삼을 초기 신뢰 앵커를 마련하는 한 가지 방법이라고 밝힙니다.
RFC 9715: UDP 기반 DNS에서 IP 단편화 회피
DNS 확장 메커니즘(EDNS(0))으로 수신 측이 받을 수 있는 UDP 메시지 크기를 알리면 서버가 큰 UDP 응답을 보낼 수 있는데, 응답이 경로상 최대 전송 단위(MTU)보다 크면 단편화가 일어납니다. 문서는 단편화된 DNS UDP 응답이 경로 밖 공격자(off-path attacker)의 캐시 오염(cache poisoning)에 노출될 수 있다고 지적합니다. 가능한 경우 응답 크기를 제한하고, 필요하면 UDP에서 TCP로 전환하라는 신호를 보내는 방식으로 단편화를 피할 수 있다고 설명합니다. 원래 BCP로 추진했으나 운영체제와 소켓 옵션의 제약 때문에 일부 권고는 아직 실제 운영 경험이 쌓이지 않아 정보 문서로 발행되었고, 경험이 쌓이면 BCP로 갱신 발행할 예정이라고 밝힙니다.
RFC 9704: 검증된 스플릿 호라이즌 환경에서 로컬 DNS 권한 확립
스플릿 호라이즌 DNS를 쓰는 네트워크에서는 특정 도메인 이름을 네트워크가 제공하는 리졸버가 권한 있게 응답합니다. 기존의 로컬 도메인 힌트(local domain hints) 전달 방식(DHCP, PvD, IKEv2 등)에는 그 특별 처리를 도메인 소유자가 승인했는지 클라이언트가 확인할 수단이 없었습니다. 이 문서는 도메인 소유자가 특정 하위 도메인에 권한 있게 응답하도록 승인한 로컬 리졸버를 DNS 클라이언트에 알리는 방식을 정의합니다. 네트워크 운영자가 로컬 DNS 서버를 안전하게 식별하고, 클라이언트는 각 로컬 도메인 힌트를 전역적으로 유효한 상위 영역과 대조해 확인합니다. 따라서 로컬 DNS 영역과 공개 영역 사이의 협력이 필요합니다.
운영·설계에 반영할 점
- 신뢰 앵커 관리 절차 점검(RFC 9718): 검증 리졸버에서 루트 신뢰 앵커를 처음 설정하는 경로와 RFC 5011 자동 갱신 사용 여부를 확인해 두는 것이 좋습니다. 내부 문서나 도구가 RFC 7958을 근거로 삼고 있다면 RFC 9718 기준으로 바꿔 두면 됩니다.
- TCP 전송 경로 확인(RFC 9715): 이 문서는 단편화를 피하는 방법으로 TCP 전환 신호에 기대므로, 권한 서버와 리졸버 모두 TCP 53 포트 통신이 방화벽이나 보안 장비에서 막히지 않는지 확인해야 합니다. 문서에 인용된 RFC 7766에 따르면 범용 DNS 구현은 UDP와 TCP를 모두 지원해야 합니다(MUST).
- EDNS 버퍼 크기·응답 크기 설정 검토(RFC 9715): 운영 중인 EDNS UDP 버퍼 크기와 응답 크기 관련 설정을 문서 3장의 권고와 비교해 보시기 바랍니다. 정보 문서이고 일부 권고는 아직 운영 경험이 적다고 밝힌 만큼, 적용할 때는 단계적으로 시험하는 편이 안전합니다.
- 스플릿 호라이즌 설계 시 고려(RFC 9704): 내부·외부 응답을 나누어 운영하는 조직은 네트워크 제공 리졸버를 기본으로 쓰지 않는 클라이언트가 이 방식으로 내부 이름을 해석할 수 있다는 점을 참고할 수 있습니다. 적용하려면 공개 영역 쪽 설정과 로컬 리졸버 식별이 함께 필요하므로, 공개 영역 관리 주체와 함께 원문 5·6장의 절차를 검토해야 합니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.