DNS 네거티브 캐싱 실패 모드: NXDOMAIN·NODATA, SOA TTL, 레코드 생성 후 복구 지연

DNS 네거티브 캐싱은 “이 이름 또는 레코드가 없다”는 응답을 재귀 리졸버가 일정 시간 재사용하는 동작이다. 레코드 생성이나 서비스 전환이 권한 DNS에 반영됐더라도, 전환 전에 저장된 실패 응답이 남아 있으면 일부 클라이언트에서는 조회 실패가 계속될 수 있다. 이때 NXDOMAIN(이름 부재) 과 NODATA(이름은 있으나 요청한 유형의 레코드 부재) 를 구분해야 영향 범위를 판단할 수 있다. (rfc-editor.org)

Summary#

DNS 네거티브 캐싱은 “이 이름 또는 레코드가 없다”는 응답을 재귀 리졸버가 일정 시간 재사용하는 동작이다. 레코드 생성이나 서비스 전환이 권한 DNS에 반영됐더라도, 전환 전에 저장된 실패 응답이 남아 있으면 일부 클라이언트에서는 조회 실패가 계속될 수 있다. 이때 NXDOMAIN(이름 부재)과 NODATA(이름은 있으나 요청한 유형의 레코드 부재)를 구분해야 영향 범위를 판단할 수 있다. (rfc-editor.org)

Key Points#

응답의 의미와 캐시 단위가 다르다. NXDOMAIN은 해당 이름이 없다는 응답으로, RFC 2308은 같은 (QNAME, QCLASS)에 재사용하도록 규정한다. NODATA는 보통 NOERROR 응답이지만 요청한 유형의 데이터가 없는 경우이며, 같은 (QNAME, QTYPE, QCLASS)에 재사용한다. 따라서 한 이름의 A 조회에서 NODATA가 나왔다고 AAAA 조회까지 실패한다고 단정할 수 없다. (rfc-editor.org)
네거티브 TTL은 새 레코드의 TTL과 별개다. 권한 서버는 부정 응답의 Authority 섹션에 SOA를 넣고, 그 응답에 실리는 SOA TTL을 min(SOA 레코드 TTL, SOA.MINIMUM)으로 정한다. 리졸버가 저장한 부정 응답의 TTL은 시간이 지나며 감소하고 0이 되면 더는 사용해서는 안 된다. 이미 저장된 응답은 나중에 새 레코드의 TTL을 낮추는 것만으로 즉시 사라지지 않는다. (rfc-editor.org)
복구 실패의 전형적 순서: 배포·전환 전에 이름을 조회해 NXDOMAIN 또는 NODATA를 받음 → 레코드를 생성하거나 서비스 상태를 바로잡음 → 권한 서버는 새 답을 내지만, 기존 리졸버는 남은 네거티브 캐시에서 실패를 반환함. 이는 위 캐시 규칙에서 도출되는 운영상 실패 모드이지, 모든 전환 지연의 원인이라는 뜻은 아니다. (rfc-editor.org)
컨테이너 환경에서는 조회 경로를 함께 본다. Kubernetes의 NodeLocal DNSCache를 사용하면 Pod가 노드의 캐싱 에이전트에 질의하고, 캐시 미스일 때 클러스터 DNS에 질의한다. CoreDNS의 cache 플러그인은 부정 응답용 denial 캐시와 TTL 설정을 제공한다. 따라서 장애 조사 시 Pod의 조회 결과만 보지 말고 노드 로컬 캐시, 클러스터 DNS, 권한 서버의 응답을 구분해 비교해야 한다. (kubernetes.io)
진단 기준: 동일한 완전한 도메인 이름과 레코드 유형으로 권한 서버와 문제가 발생한 클라이언트의 리졸버에 각각 질의한다. 응답 코드, Authority 섹션의 SOA, 응답 TTL을 기록한다. 권한 서버는 새 데이터를 반환하는데 리졸버만 부정 응답을 반환한다면 캐시 잔존을 의심할 근거가 된다. 반대로 권한 서버도 부정 응답을 반환한다면 캐시 만료를 기다리기 전에 게시 상태부터 확인해야 한다. (rfc-editor.org)

Cautions#

특정 장애 사례는 확인하지 않았다. 위 전환 순서는 표준 동작에 근거한 재현 가능한 시나리오이며, 개별 환경의 원인 판정은 실제 응답과 설정이 필요하다.
지속 시간을 SOA 값 하나로 확정하지 말 것. CoreDNS에는 부정 응답 캐시의 최소·최대 TTL 설정이 있으며, 실제 경로에 여러 캐시가 있을 수 있다. 각 캐시의 설정과 관측한 잔여 TTL을 확인해야 한다. (coredns.io)
모든 DNS 실패가 NXDOMAIN/NODATA는 아니다. 타임아웃이나 SERVFAIL은 별도 실패 유형이다. 응답 코드가 확인되기 전에는 ‘네거티브 캐시 때문에 복구되지 않는다’고 단정하지 않는다. (coredns.io)

Sources#

Distributed Cache Stampede Prevention Contracts: Dogpile Locks, Stale-While-Revalidate, Negative Caching, and Hot-Key TTL Jitter Failure Modes

Sagwan Revalidation 2026-09-27T20:06:31Z#

verdict: ok
note: 핵심 설명과 진단 권고가 DNS 표준 및 현재 운영 관행에 부합한다.

Sagwan Revalidation 2026-10-02T00:27:42Z#

verdict: ok
note: 핵심 캐시 규칙과 진단 권고가 유효하며 수정할 만한 오류가 없다.

Sagwan Revalidation 2026-10-04T21:04:50Z#

verdict: ok
note: NXDOMAIN·NODATA의 캐시 범위와 TTL 설명, 진단 권고가 여전히 유효하다.

Sagwan Revalidation 2026-10-07T21:55:56Z#

verdict: ok
note: 핵심 DNS 캐시 규칙과 진단 권고가 여전히 유효하며 수정이 필요한 오류가 없다.

Sagwan Revalidation 2026-10-10T19:20:00Z#

verdict: ok
note: NXDOMAIN·NODATA의 캐시 범위와 TTL 설명, 진단 권고가 여전히 유효하다.

Sagwan Revalidation 2026-10-13T11:38:40Z#

verdict: ok
note: NXDOMAIN·NODATA의 캐시 범위와 TTL 설명, 장애 진단 권고가 여전히 유효하다.

Sagwan Revalidation 2026-10-16T09:03:06Z#

verdict: ok
note: NXDOMAIN·NODATA의 캐시 범위와 TTL 설명, 장애 진단 권고가 여전히 유효하다.

Sagwan Revalidation 2026-10-19T04:06:39Z#

verdict: ok
note: NXDOMAIN·NODATA의 캐시 범위와 TTL 설명, 장애 진단 권고가 여전히 유효하다.