2026년 7월 1일 IETF가 DNS 관련 RFC 3건을 발행했습니다. RFC 10026은 상위 영역 운영자가 하위 영역에서 보낸 DNSSEC 위임 서명자(DS) 정보를 자동으로 받아들일 때 따를 운영 권고입니다. 최선 현행 관행(BCP) 246으로 발행됐습니다. RFC 10029는 질의 한 번으로 여러 레코드 유형을 함께 요청하는 확장 DNS 메커니즘(EDNS) 옵션을 정의한 표준 제안(Proposed Standard)입니다. RFC 10023은 도메인 이름을 팔 의사가 있음을 DNS로 알리는 _for-sale 레코드 규약을 담은 정보 문서(Informational)입니다.
한눈에 보기
| RFC 번호 | 제목 | 종류 | 대체·갱신하는 RFC | 적용 대상 |
|---|---|---|---|---|
| RFC 10026 | DNSSEC 위임 서명자(DS) 자동화 운영 권고 | 현행 모범 사례 (BCP 246) | 없음 | 상위 영역 운영자(레지스트리·레지스트라), 하위 영역 운영자 |
| RFC 10029 | DNS 다중 질의 유형(Multiple QTYPEs) EDNS 옵션 | 표준 제안 (Proposed Standard) | 없음 | 리졸버, 권한 DNS 서버, 방화벽·중간 장비 |
| RFC 10023 | _for-sale 밑줄 접두 전역 범위 DNS 노드 이름 |
정보 문서 (Informational) | 없음 | 도메인 보유자, 영역 운영자 |
건별 내용
RFC 10026: DNSSEC 위임 서명자(DS) 자동화 운영 권고
RFC 7344, 8078, 9615에 따르면 하위 영역은 하위 DS(CDS)나 하위 DNSKEY(CDNSKEY) 레코드를 게시해 원하는 DNSSEC 위임 정보를 알릴 수 있습니다. 이를 받아 반영하는 상위 측 주체를 상위 에이전트(Parental Agent)라고 하며, 보통 레지스트리나 레지스트라가 이 역할을 맡습니다. 상위 에이전트는 수용 검사, 오류·성공 통보, 동시 갱신 같은 다자간 문제에 대해 여러 결정을 내려야 합니다. 이 문서는 그 결정에 대한 권고를 정리했습니다. 원문은 지금까지 구축된 DS 자동화가 서로 다르게 선택해 동작이 일관되지 않았다고 지적합니다. 등록인-레지스트라-레지스트리(RRR) 모델에서는 레지스트라와 레지스트리가 모두 위임을 바꿀 수 있다는 점도 함께 다룹니다. 이 RFC를 따르려면 최소한 DNSSEC 부트스트래핑(RFC 9615)과 이후 갱신(RFC 7344, 8078)을 모두 지원해야 합니다.
RFC 10029: DNS 다중 질의 유형(Multiple QTYPEs)
예를 들어 A, AAAA, HTTPS 레코드를 질의 여러 번이 아니라 한 번에 받으려는 요구를 위한 방법입니다. 원문은 기존 방법이 이 요구를 채우지 못한다고 설명합니다. RFC 9619는 QUERY 요청에 질문을 하나만 허용합니다. QTYPE=ANY로 질의해도 응답 측은 RRset 하나만 골라 돌려줄 수 있습니다(RFC 8482). 이 문서는 질의에 쓰는 MQTYPE-Query(20)와 응답에 쓰는 MQTYPE-Response(21) EDNS 옵션을 정의합니다. 응답용 옵션을 따로 둔 것은 EDNS 옵션을 그대로 되돌려 보내는 중간 장비(middlebox)에 대비하기 위해서입니다. 스텁 리졸버→재귀 서버, 재귀 리졸버→권한 서버 구간에 모두 적용됩니다. 멀티캐스트 DNS(mDNS)에는 적용되지 않고, DNS 기반 서비스 탐색(DNS-SD)에는 적용됩니다. 형식이 잘못된 요청에는 FORMERR로 응답해야 합니다. 예를 들어 MQTYPE-Query 옵션이 둘 이상이거나, QT 목록이 비었거나, 중복 값이나 메타 RRTYPE이 들어 있는 경우입니다. 이 확장을 지원하는 서버는 응답이 잘렸더라도(TC=1) MQTYPE-Response를 넣어야 합니다.
RFC 10023: _for-sale 밑줄 접두 전역 범위 DNS 노드 이름
도메인 보유자가 영역에 예약된 밑줄 접두 리프 노드 이름 _for-sale을 두고 TXT 레코드를 넣으면, 상위 도메인 이름을 살 수 있다는 뜻이 됩니다. 운영 규약일 뿐이라 프로토콜을 바꿀 필요가 없습니다. 도메인을 실제로 쓰는 중에도 적용할 수 있고, 필요할 때 켜고 끌 수 있습니다. 레코드는 버전 태그 v=FORSALE1;로 시작해야 하며, 그 뒤에 fcod=, ftxt=, furi=, fval= 중 하나를 붙일 수 있습니다. 레코드 하나에는 태그-값 쌍을 하나만 넣습니다. 원문은 이 내용이 자동 처리나 문자열 비교보다는 사람이 읽고 확인하는 용도라고 밝힙니다.
운영자가 할 일
- DS 자동화(RFC 10026): 하위 영역 운영자라면 CDS/CDNSKEY 게시 절차를 점검하고, 쓰는 레지스트리·레지스트라가 DS 자동화를 어떻게 처리하는지 확인하세요. 상위 에이전트 역할을 한다면 수용 검사, 통보, 동시 갱신 처리 방식을 이 권고와 비교해 보세요. 세부 권고는 원문 부록 A에 모여 있습니다.
- 다중 질의 유형(RFC 10029): 새로 정의된 EDNS 옵션 코드 20, 21이 방화벽이나 중간 장비에서 막히거나 바뀌지 않는지 확인하세요. 사용 중인 DNS 소프트웨어가 지원하는지는 각 제품 공지에서 확인하세요.
_for-sale규약(RFC 10023): 이 규약을 쓰려면 원문 2장의 형식(v=FORSALE1;버전 태그, 태그-값 쌍 1개)에 맞춰 TXT 레코드를 넣으세요. 원문 부록 A에 예시가 있습니다.- 세 문서 모두 원문을 직접 확인하고, 자체 운영 정책에 반영할지 검토하세요.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.