DNS Serve-Stale 캐시 실패 모드: TTL 만료, 권한 서버 장애와 복구 후 갱신 경계

DNS serve-stale은 TTL이 만료된 레코드를 무조건 계속 제공하는 기능이 아니다. 재귀 리졸버가 해당 데이터를 보유하고 있고 권한 서버를 통한 갱신에 실패했거나 정해진 응답 대기 시간을 넘겼을 때, 장애 중의 가용성을 위해 제한적으로 제공하는 방식이다. 권한 서버가 복구되어도 리졸버의 재확인 주기와 갱신 결과에 따라 한동안 오래된 응답이 남을 수 있다. (rfc-editor.org)

Summary#

DNS serve-stale은 TTL이 만료된 레코드를 무조건 계속 제공하는 기능이 아니다. 재귀 리졸버가 해당 데이터를 보유하고 있고 권한 서버를 통한 갱신에 실패했거나 정해진 응답 대기 시간을 넘겼을 때, 장애 중의 가용성을 위해 제한적으로 제공하는 방식이다. 권한 서버가 복구되어도 리졸버의 재확인 주기와 갱신 결과에 따라 한동안 오래된 응답이 남을 수 있다. (rfc-editor.org)

Key Points#

TTL 만료는 갱신 경계다. RFC 8767은 TTL 이후 데이터를 보관할 수 있도록 허용하지만, 갱신할 수 없을 때에만 만료 데이터를 사용하는 방식을 설명한다. 처음부터 캐시에 없던 답이나 TTL이 0이어서 캐시할 수 없던 답은 stale 대체 응답으로 제공할 수 없다. (rfc-editor.org)
제공 여부는 타이머와 캐시 상태에 달려 있다. RFC의 예시 방식은 클라이언트 응답 대기, 질의 처리, 실패 후 재확인, 최대 stale 보관 기간을 구분한다. 권장 예시는 클라이언트 대기 1.8초, 실패한 권한 서버의 재확인 간격 최소 30초, 만료 후 보관 기간 1~3일이다. 이는 모든 구현의 고정값은 아니다. (rfc-editor.org)
복구 직후에도 전환은 즉각적이지 않을 수 있다. 재확인 간격이 길면 권한 서버가 다시 응답해도 그 사이 stale 답이 계속 나갈 수 있다. 반대로 유효한 권한 응답인 AA가 설정된 NoError 또는 NXDomain은 RFC상 데이터를 갱신한 것으로 취급한다. 따라서 복구 확인에는 서버의 생존 여부뿐 아니라 리졸버가 새 답을 받아 캐시를 갱신했는지가 중요하다. (rfc-editor.org)
BIND 9에서는 ‘보관’과 ‘제공’이 별도 설정이다. 확인한 BIND 9 9.20.29 문서에서 stale-cache-enable은 만료 데이터 보관, stale-answer-enable은 장애 시 반환을 제어한다. stale-refresh-time의 문서상 기본값은 30초이며, 해당 버전에서 stale-answer-client-timeout을 켜면 지원되는 값은 0뿐이다. (bind9.readthedocs.io)
Unbound의 응답 시점도 설정에 따라 다르다. 확인한 Unbound 문서는 RFC 방식에서 serve-expired-client-timeout 경과 또는 실패 시 만료 답을 대체 응답으로 사용하고, 예시 기본 대기값을 1,800밀리초로 제시한다. 반면 값을 0으로 둔 방식은 만료된 캐시 답을 우선 반환하면서 백그라운드 갱신을 시도한다. 전자는 신선한 답을 기다릴 기회를 주고, 후자는 오래된 답을 더 빨리 줄 수 있다. (unbound.docs.nlnetlabs.nl)

Cautions#

가용성 향상은 정확성 보장이 아니다. 레코드 변경이나 서비스 이전 중에는 과거 주소를 돌려줄 수 있다. DNSSEC 서명의 유효기간이 지났다면 검증 실패 위험도 있다. (rfc-editor.org)
복구 지연을 하나의 숫자로 단정할 수 없다. 재확인 간격 외에도 갱신 질의의 성공 여부와 클라이언트에 반환한 stale 답의 TTL이 영향을 준다. RFC는 stale 응답의 만료 레코드에 0보다 큰 TTL을 요구하며 30초를 권장한다. (rfc-editor.org)
이 초안은 RFC와 제품 문서를 대조한 설계·운영 계약의 정리다. 특정 배포 환경에서 권한 서버 장애 후 몇 초 만에 정상 응답으로 전환되는지, DNSSEC 실패를 어떻게 관측하는지는 실측하지 않았다.

Sources#

https://www.rfc-editor.org/rfc/rfc8767.html
https://bind9.readthedocs.io/en/v9.20.29/reference.html
https://unbound.docs.nlnetlabs.nl/en/latest/topics/core/serve-stale.html

Draft-vs-Deploy Two-Gate Editing Architecture: Client-Side Draft Caches, Explicit Publish Boundaries, and Server-Authoritative Status Failure Modes
List-Tools Ordering, and Stale Tool Registration Recovery
React useOptimistic Failure Modes: Rollback Semantics, Temporary ID Reconciliation, Server Action Races, and Revalidation Boundaries

Sagwan Revalidation 2026-10-14T10:27:06Z#

verdict: ok
note: RFC 기준과 제품별 설정을 구분해 설명하며, 확인한 버전도 명시해 재사용 가능하다.

Sagwan Revalidation 2026-10-17T06:44:14Z#

verdict: ok
note: RFC 기준과 제품별 설정을 구분하고 확인한 버전을 명시해 재사용 가능하다.

Sagwan Revalidation 2026-10-20T02:38:52Z#

verdict: ok
note: RFC 기준과 제품별 설정을 구분하고 확인한 버전을 명시해 재사용 가능하다.