IETF가 2020년 11월 30일 RFC 8945 "Secret Key Transaction Authentication for DNS (TSIG)"를 발표했습니다. 이 문서는 공유 비밀 키와 단방향 해시로 DNS 트랜잭션을 인증하는 트랜잭션 서명(TSIG, Transaction Signature) 프로토콜을 다시 정의합니다. 인터넷 표준(Internet Standard) STD 93으로 지정되었고, 기존 규격인 RFC 2845와 RFC 4635를 대체(obsolete)합니다.
무엇이 발표되었나
RFC 8945는 키를 쓰는 해시 함수로 만든 메시지 인증 코드(MAC, Message Authentication Code)로 DNS 트랜잭션의 지점 간(point-to-point) 인증과 무결성을 확인하는 방법을 정합니다. 원문에 적힌 주요 용도는 다음과 같습니다.
- 동적 업데이트(dynamic update) 요청이 승인된 클라이언트에서 왔는지 인증
- 응답이 승인된 네임 서버에서 왔는지 인증
- 영역 전송(zone transfer) 보호: 글루(glue) 레코드를 포함한 영역 전송 전체가 보호 범위입니다. 원문은 DNSSEC이 글루 레코드와 서명되지 않은 레코드를 보호하지 않는다는 점을 함께 짚습니다.
동작 방식도 원문에 정리되어 있습니다. 질의의 MAC은 메시지 내용과 미리 합의한 TSIG 키로 계산합니다. 응답의 MAC을 계산할 때는 질의의 MAC도 입력에 넣습니다. 응답이 여러 패킷으로 나뉘면 두 번째 패킷부터는 앞 패킷의 MAC을 입력에 포함합니다. 이 방식으로 패킷 순서가 중간에 끊긴 것은 알아낼 수 있지만, 전송이 일찍 끝난 것까지 알아내지는 못합니다. MAC은 DNS 메시지 추가(additional) 섹션의 TSIG 자원 레코드에 담깁니다.
개정 배경도 원문에 나옵니다. 2017년에 RFC 2845와 RFC 4635를 그대로 따른 네임 서버 구현 두 곳에서 이 기능과 관련된 보안 문제(CVE-2017-3142, CVE-2017-3143, CVE-2017-11104)가 발견되었습니다. 해당 구현은 수정되었고, 비슷한 문제가 다시 생기지 않도록 규격을 새로 정리한 것이 이 문서입니다.
영향 범위
TSIG로 영역 전송이나 동적 업데이트를 인증하는 DNS 서버와 클라이언트가 모두 해당됩니다. 원문에 따르면 TSIG는 두 당사자가 사용할 알고리즘과 키를 미리 합의했다는 것을 전제로 합니다. 공유 비밀 키를 어떻게 배포할지는 이 문서에서 권고하지 않으며, 네트워크 관리자가 대역 외(out-of-band) 방법으로 정적으로 설정할 것을 예상합니다.
원문은 적용 범위의 한계도 밝힙니다. 공유 키의 수가 서버 수의 제곱에 비례해 늘어나므로, 일반적인 서버 간 인증이나 많은 서버와 통신하는 서버에는 맞지 않습니다. 반면 소수의 재귀 서버와만 통신하는 여러 호스트의 리졸버에는 적합하다고 설명합니다.
운영자가 할 일
- TSIG 비밀 키는 개인 키와 같은 수준으로 보호해야 합니다. 원문은 키가 노출되면 제3자가 MAC을 위조해 정당한 당사자로 위장할 수 있다고 경고합니다. 설정 파일 접근 권한과 키 보관 위치를 점검하세요.
- 키는 대역 외 방법으로 배포하고, TSIG를 쓰는 서버 쌍마다 알고리즘과 키가 서로 맞게 설정되어 있는지 확인하세요.
- 위 2017년 CVE에 해당하는 구현을 아직 쓰고 있다면, 각 소프트웨어 공급자의 보안 공지를 보고 수정된 버전인지 확인하세요.
- 영역 전송이나 동적 업데이트에 아직 인증을 적용하지 않았다면 TSIG 도입을 검토하세요.
자세한 내용은 RFC 8945 원문을 참고하세요.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.