IETF가 2021년 12월 RFC 9157 "Revised IANA Considerations for DNSSEC"를 표준 트랙 제안 표준(Proposed Standard)으로 발행했습니다. 위임 서명자(DS, Delegation Signer) 레코드의 다이제스트 알고리즘과 NSEC3(NextSECure version 3)의 해시 알고리즘·플래그를 IANA 레지스트리에 올리는 절차를 'Standards Action'에서 'RFC Required'로 낮춰, 다른 DNSSEC 암호 알고리즘과 같은 기준을 적용하도록 한 문서입니다. DNS 프로토콜 동작은 바뀌지 않습니다. 다만 앞으로 레지스트리에는 IETF 검토를 거치지 않은 알고리즘이 더 많이 올라올 수 있습니다.
무엇이 발표되었나
RFC 6014는 DNSSEC 암호 알고리즘 식별자의 할당 요건을 'Standards Action'에서 'RFC Required'로 이미 낮췄습니다. 그러나 DS 레코드용 해시 알고리즘(RFC 3658)과 NSEC3용 해시 알고리즘(RFC 5155)은 계속 'Standards Action'으로 남아 있었습니다. RFC 9157은 이 차이를 없앴습니다. 주요 내용은 다음과 같습니다.
- RFC 6014 갱신: RFC 문서로 충분히 설명된 DS 해시 알고리즘, NSEC3 해시 알고리즘, NSEC3 파라미터, NSEC3 플래그라면 IANA 레지스트리에서 식별자를 받을 수 있습니다. RFC 5155와 RFC 6014의 관련 요건도 함께 갱신합니다.
- IANA 레지스트리 변경
- "DNSSEC NSEC3 Parameters" 레지스트리의 "DNSSEC NSEC3 Flags", "DNSSEC NSEC3 Hash Algorithms", "DNSSEC NSEC3PARAM Flags" 등록 절차를 'RFC Required'로 바꿨습니다.
- "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" 레지스트리의 "Digest Algorithms" 등록 절차를 'RFC Required'로 바꿨습니다.
- RFC 8624 갱신: 표준 트랙이 아닌 RFC에 정의된 DNSKEY·DS 알고리즘에 대해서도 권고를 낼 수 있도록 RFC 8624 1.2절 둘째 문단을 고쳤습니다. 이 문서에 언급되지 않았더라도 레지스트리에 있는 알고리즘은 구현해도 된다(MAY)는 원칙은 그대로입니다. MAY는 MUST나 RECOMMENDED에서 강등된 알고리즘에만 붙입니다.
RFC Editor 페이지에 따르면 RFC 9157은 이후 RFC 9904로 갱신되었습니다.
영향 범위
- 이 문서는 IANA 등록 절차와 구현 권고 문구를 바꾼 것입니다. 기존 DS 다이제스트나 NSEC3 해시 알고리즘의 동작, 그리고 이미 서명한 영역(zone)은 영향을 받지 않습니다.
- RFC는 보안 고려 사항(Security Considerations)에서 등록 문턱이 낮아지면 좋은 알고리즘과 나쁜 알고리즘 모두 레지스트리에 올리기 쉬워진다고 밝히고 있습니다. 그리고 그 보안 영향은 가늠하기 어렵다고 적고 있습니다.
- 서명한 영역의 관리자나 검증 리졸버(validating resolver) 운영자가 IANA 레지스트리 내용을 기준으로 보안 판단을 해 왔다면 이번 변경에 영향을 받습니다.
운영자가 할 일
- 레지스트리 등재 여부를 안전성의 근거로 쓰지 않기: RFC 9157은 IANA 레지스트리를 보고 보안 판단을 하는 것은 원래도 좋지 않았지만, 앞으로는 더 나쁜 방법이 된다고 지적합니다. 어떤 알고리즘이 안전한지는 보안 문헌을 읽고 판단하라고 권고합니다.
- 알고리즘 선택 정책 점검: 영역 서명이나 DS 등록에 쓸 알고리즘, 리졸버가 검증할 알고리즘을 고를 때 "레지스트리에 있으니 사용 가능"이라는 기준을 쓰고 있다면 바꾸는 것이 좋습니다. 구현 권고 수준은 RFC 8624와 이를 갱신한 문서를 참고해 다시 확인하십시오.
- 당장 설정을 바꿔야 하는 사항은 없습니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.