IETF가 2021년 4월 5일 표준화 과정 문서(Proposed Standard)로 RFC 9018 「Interoperable Domain Name System (DNS) Server Cookies」를 발표했습니다. DNS 쿠키(DNS Cookies)를 정의한 RFC 7873을 개정하는 문서입니다. 서버 쿠키(Server Cookie)를 만드는 방법을 정확히 정해, 서로 다른 DNS 소프트웨어로 구성한 애니캐스트(anycast) 서버 묶음에서도 표준 클라이언트와 쿠키를 주고받을 수 있게 했습니다.
무엇이 발표되었나
RFC 7873의 DNS 쿠키는 가벼운 DNS 트랜잭션 보안 장치입니다. 통신 경로 밖에 있는 공격자(off-path attacker)가 시도하는 서비스 거부(DoS) 증폭, 위조, 캐시 오염(cache poisoning) 공격을 일부 막아 줍니다.
RFC 7873 6절은 애니캐스트 서버들이 같은 서버 비밀값(Server Secret)을 쓰도록 권고했습니다. 그러나 그 비밀값으로 서버 쿠키를 어떻게 계산하는지는 각 구현에 맡겼습니다. 그 결과 구현마다 계산 방식이 달라졌습니다. 비밀값을 공유해도 한 구현이 만든 서버 쿠키를 다른 구현이 검증하지 못하는 경우가 많았습니다. 그래서 여러 벤더 제품을 섞어 쓰는 애니캐스트 망에서는 DNS 쿠키를 운영하기 어려웠습니다.
RFC 9018이 바꾸거나 추가한 내용은 다음과 같습니다.
- RFC 7873 부록 A.1과 B.1의 "단순한" 클라이언트·서버 쿠키 예시 알고리즘은 현재 보안 기준으로는 너무 약합니다. 따라서 사용해서는 안 됩니다(MUST NOT).
- 부록 B.2의 "더 복잡한" 서버 알고리즘 예시는 RFC 9018 4절의 상호 운용 규격으로 대체됩니다. 서버 쿠키 구현은 이 규격을 따라야 합니다(MUST).
- 부록 A.2의 클라이언트 쿠키 예시는 권장하지 않습니다(NOT RECOMMENDED). 대신 3절에서 클라이언트를 보호하는 생성 방식을 제안합니다.
- 서버 비밀값을 교체하는 방법을 제안합니다.
- 서버 쿠키 생성 방식과 의사난수 함수(pseudorandom function)를 등록하는 IANA 레지스트리를 새로 만들었습니다. 발표 시점에는 이 문서의 방식이 유일한 항목입니다.
클라이언트(리졸버) 쿠키는 구현끼리 호환될 필요가 없습니다. 클라이언트가 자기 쿠키만 알아보면 되기 때문입니다. 다만 RFC 9018은 다음과 같이 권고합니다.
- 클라이언트는 서버 IP 주소마다 다른 클라이언트 쿠키를 써야 합니다(MUST).
- 클라이언트 쿠키는 64비트 엔트로피를 갖는 것이 좋습니다(SHOULD).
- 쿠키를 지원하지 않는 서버에 같은 클라이언트 쿠키를 다시 보내서는 안 됩니다(MUST NOT). 일정 시간(예: 5분)이 지난 뒤 새 쿠키로 다시 시도하는 것이 좋습니다.
영향 범위
- 여러 DNS 소프트웨어를 섞어 애니캐스트로 권한 서버나 리졸버를 운영하는 곳이 주로 영향을 받습니다.
- 단일 구현이나 애니캐스트가 아닌 서비스도 영향이 있습니다. 동작과 보안 특성이 널리 검토된 표준 알고리즘을 쓸 수 있게 됩니다.
- DNS 쿠키를 구현한 서버·클라이언트 소프트웨어 개발자도 대상입니다. 서버 쿠키는 RFC 9018 4절 방식을 따라야 합니다.
운영자가 할 일
- 쓰고 있는 DNS 소프트웨어가 RFC 9018 방식의 서버 쿠키를 지원하는지 제품 문서에서 확인하세요.
- 애니캐스트 서버 묶음에서 DNS 쿠키를 쓰려면 모든 노드가 같은 생성 방식과 같은 서버 비밀값을 쓰는지 확인하세요.
- 서버 비밀값을 교체할 때는 RFC 9018의 교체 방법 제안을 참고하세요.
- 상세 규격은 원문 RFC 9018에서 확인하세요.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.