요약

  • RFC 8767는 리졸버가 만료된 DNS 데이터를 보관하고 때로는 반환하는 것을 허용하지만, 선의의 갱신 시도가 사용 가능한 권위적 데이터를 얻지 못한 후에만 한정된 대체 수단으로 가능하다.
  • 원본 TTL, 최대 stale 보존 기간, 클라이언트 대기 예산, 반환되는 stale TTL, DNSSEC 서명 유효성, 진단 신호, 재시도 주기는 서로 다른 시계이자 서로 다른 주장이다.
  • David C. Lawrence의 공동 저자 기록은 집단적 IETF 메커니즘에 대한 기여를 나타낼 뿐이며, 그가 이나 리졸버나 stale 사본이 원본 데이터에 대한 권위가 된다는 뜻은 아니다.

캐시된 응답이 막 TTL 0을 넘었다. 클라이언트 하나가 기다리고 있다. 권위적 서버들은 리졸버의 인내가 다하기 전에 사용 가능한 응답을 내지 못한다. 이제 세 가지 진술이 동시에 참일 수 있다: 응답은 만료되었고, 그래도 장애보다는 나을 수 있으며, 다시 신선해진 것은 아니다.

세 번째 진술이 어려운 부분이다. 연속성 메커니즘은 자신이 보존하는 서비스의 언어를 물려받는 경향이 있다. 응답이 도착하면 대시보드는 DNS가 성공했다고 말한다. 이름이 풀리면 애플리케이션은 진행한다. 리졸버가 정밀한 영수증을 남기지 않는 한, 오래된 사본의 예외적 사용은 평범한 성공 카운트 안에 사라져 버릴 수 있다.

David C. Lawrence, Warren Kumari, Puneet Sood가 저술해 2020년 3월 제안 표준(Proposed Standard)으로 발표된 RFC 8767은 만료된 DNS 데이터에 한정된 운영적 상태를 부여한다. 이는 TTL을 폐지하지 않는다. 존의 권위와, 원본 경로가 사용 불가능할 때 재귀 리졸버가 애플리케이션을 계속 움직이게 하는 일시적 능력을 분리한다.

만료가 곧 바이트가 사라졌다는 뜻은 아니다

RFC 1035는 TTL을 자원 레코드를 캐시할 수 있는 구간, 즉 그 이후에는 원본을 다시 조회해야 하는 간격으로 정의한다. RFC 2181은 리졸버의 의무를 명확히 한다: TTL이 캐시 사용을 제한하며, 리졸버는 그 한도 이후 데이터가 여전히 유효한 것처럼 행동해서는 안 된다.

구현이 타이머가 0이 되는 순간 바이트를 지워야 하는 것은 아니다. 진단이나 예외적 복구를 위해 만료된 RRset을 내부적으로 보관할 수 있다. 그러나 저장과 응답 허용은 다른 상태다. 메모리에 있는 레코드는 아직 리졸버가 반환할 수 있는 레코드가 아니다.

RFC 8767은 이 구분을 통제된 대체 수단으로 만든다. 리졸버는 만료된 데이터를 유지하고, 권위적 원본에서 갱신할 수 없을 때 그것을 사용할 수 있다. 이 메커니즘이 가치 있는 이유는 많은 권위적 장애가 마지막으로 알려진 응답의 운영적 유용성보다 짧기 때문이다. 일시적 라우팅 문제, 접근 불가능한 서버 집합, 로컬 타임아웃이 즉시 사용자에게 보이는 장애가 될 필요는 없다.

이 예외에는 놓치기 쉬운 경계가 있다: 원래 TTL 0으로 수신된 데이터는 이 대체 수단에 들어갈 수 없다. 발행자가 캐시 재사용을 명시적으로 금지했기 때문이다. 애초에 캐시 가능하지 않았던 값에 대해 리졸버가 stale 수명을 만들어낼 수는 없다.

따라서 첫 번째 운영적 영수증은 사건 이전에 시작된다: RRset, 클래스, 타입, 원본 응답 출처, 수신된 TTL, 삽입 시각, 평균 만료 시각, 검증 상태. 이 필드들이 없으면 “이전 응답을 제공했다”는 말은 어떤 응답인지, 얼마나 오래되었는지, 재사용 자격이 있었는지를 증명하지 못한다.

권위적 경로가 첫 번째 기회를 얻는다

serve-stale은 접근 가능한 원본보다 가까운 오래된 사본을 선호하는 허가증이 아니다. RFC 8767은 선의의 최근 갱신 시도를 요구한다. 리졸버는 권위적 경로에 질의하고, 구성된 클라이언트 응답 예산만큼 기다리고, 시도가 실패하거나 시간 초과된 후 stale 데이터를 사용할 수 있다. 최근 시도가 이미 상위 장애를 확인했다면, 이후 질의는 같은 지연을 클라이언트마다 반복하는 대신 즉시 stale 데이터를 참조할 수 있다.

이 순서는 존 소유자가 응답을 바꿀 수 있는 능력을 보호한다. 편리할 때마다 리졸버가 stale 데이터를 먼저 돌려준다면, 긴급 주소 변경, 인증서 관련 DNS 변경, 서비스 철수는 권위적 서비스가 건강한 상태에서도 보이지 않을 수 있다. 연속성은 책임 없는 대체가 된다.

“선의”에는 관찰 가능한 정의가 필요하다. 기록에는 시도한 상위 대상, 전송 방식, 시작·종료 시각, 응답 또는 실패 분류, 재시도 정책, 결정에 재사용된 최근 실패 상태가 담겨야 한다. 타임아웃, SERVFAIL, 네트워크 접근 불가, 검증 실패, 권위적 부정 응답은 서로 바꿔 쓸 수 없다.

이 구분은 성공한 stale 응답이 복구로 오인되는 것도 막는다. 클라이언트는 무언가를 받았지만, 리졸버는 원본 경로를 수리하지 않았다. RFC 8767은 갱신 시도를 계속 요구한다. 복구는 사용 가능한 권위적 데이터를 얻어 평가하고 현재 캐시 상태로 설치했을 때만 발생한다.

하나의 응답에는 여러 개의 시계가 있다

가장 위험한 단순화는 하나의 타이머가 메커니즘 전체를 지배하는 것처럼 “stale TTL”을 말하는 것이다. 최소 여섯 개의 시계가 관련된다.

원본 TTL은 권위적 데이터에서 왔으며 평균적 신선도를 정의한다. RFC 8767은 보존 기간 계산에 사용되는 수신 TTL 상한도 논의하며, 비정상적으로 큰 원본 값이 무한한 stale 수평선을 만들지 않도록 7일을 제안한다.

최대 stale 수명은 별도의 리졸버 정책이다. RFC는 이를 구성 가능해야 한다고 말하며, 대략 1~3일 규모의 값을 제안한다. 그 경계에 도달하면 바이트가 여전히 저장되어 있더라도 응답은 stale 자격을 잃는다.

클라이언트 대기 예산은 대체 수단으로 응답하기 전에 갱신 시도에 얼마나 허용하는지를 정한다. 일 단위가 아니라 초 단위일 수 있다. 짧은 예산은 애플리케이션 응답성을 높이지만 느린 원본 응답이 경쟁에서 지고 틀리는 확률을 높인다.

반환되는 stale TTL은 하위 클라이언트에 이 예외적 응답을 얼마나 재사용할 수 있는지를 알려준다. RFC 8767은 양수 값을 요구하고 30초를 권고한다. 이 값은 레코드의 권위적 나이를 초기화하지 않는다. 다음 캐시의 대체 수단 재사용을 제한할 뿐이다.

DNSSEC 서명에는 고유의 유효 시작 시각과 만료 시각이 있다. RRset은 평균 TTL은 지났지만 서명은 여전히 시간적으로 유효할 수 있고, 리졸버의 stale 보존 창이 열려 있는 동안 서명이 만료될 수도 있다. 캐시 정책은 암호학적 시간을 연장할 수 없다.

마지막으로 갱신 재시도에는 주기가 있다. 리졸버는 원본 장애를 과도한 질의 폭풍으로 바꾸지 않으면서 현재 데이터를 계속 요청해야 한다. 백오프와 실패 기억은 복구 시간과 상위 부하 모두에 영향을 준다.

유용한 레코드는 이들을 하나의 기간으로 압축하지 않는다. 원본 만료, stale 자격 기한, 클라이언트 결정 시각, 응답 TTL, 서명 구간, 다음 갱신 시도를 각각 별도로 보존한다.

DNSSEC는 오래된 응답을 인증할 수 있지만, 그것을 현재로 만들지는 않는다

RFC 4035는 검증 리졸버에게 DNSSEC 체인과 서명 유효 구간을 확인하도록 요구한다. 그 결과는 보안 평가이지 신선도 증명서가 아니다. stale RRset은 서명이 유효하고 체인이 사용 가능하면 암호학적으로는 여전히 검증을 통과할 수 있다. 서명이 만료되거나 지원 체인이 바뀌면 Bogus가 되거나 다른 방식으로 사용 불가능해질 수도 있다.

RFC 8767은 stale 데이터가 나이를 먹을수록 검증 실패가 더 가능해진다고 경고한다. 또한 적대적 시나리오를 지적한다: 권위적 서비스를 계속 사용 불가능하게 만들 수 있는 공격자는 더 오래된 응답의 수명을 연장할 수 있다. 이는 서명 위조를 필요로 하지 않는다. “소유자가 과거 어느 시점에 서명했다”와 “여전히 소유자가 의도한 현재 상태다”의 차이를 이용할 뿐이다.

이 리스크는 소비자가 DNS로 되돌릴 수 없는 행위를 승인할 때 급격해진다. RFC는 인증 기관(CA)이 DNS 기반 검증에 stale 리졸버에 의존하지 않도록 구체적으로 경고한다. 뉴스 사이트 접속에는 합리적인 연속성 선택이, 소유자가 철회하거나 바꾸려 한 응답을 원천으로 인증서를 발급할 때는 부적절할 수 있다.

부정 응답도 똑같은 주의가 필요하다. stale 긍정 응답은 트래픽을 오래된 서비스로 계속 가리킬 수 있다. stale NXDOMAIN은 새로 만든 이름을 계속 보이지 않게 할 수 있다. RFC 8914는 후자에 Stale NXDOMAIN Answer라는 고유 진단 코드를 부여했는데, 부재도 나이가 중요한 하나의 주장이기 때문이다.

따라서 리졸버 영수증에는 상황에 따라 Secure, Insecure, Bogus, Indeterminate 처리, 서명 시각, 부정 응답 증명 상태, 정책이 사용처별로 다르다면 소비자 클래스를 포함해야 한다. “DNSSEC 통과”가 “데이터는 만료되었다”를 지워서는 안 된다.

신호는 치료제가 아니라 증인이다

Lawrence가 공동 저자이기도 한 RFC 8914는 Extended DNS Errors를 정의한다. 코드 3은 Stale Answer를, 코드 19는 Stale NXDOMAIN Answer를 식별한다. 능력 있는 클라이언트, 중개자, 운영자는 이 채널로 예외적 연속성 응답을 평범한 현재 데이터와 구분할 수 있다.

EDE는 그 자체로 DNS RCODE를 바꾸지 않는다. RRset을 인증하지도, 권위적 경로가 실패한 이유를 증명하지도, 서명을 연장하지도, 애플리케이션이 신호를 봤다는 보장을 하지도 않는다. 많은 클라이언트는 여전히 평범한 응답 필드만 소비한다.

이 한계가 EDE를 면죄부가 아니라 유용한 증거로 만든다. 리졸버는 stale 응답을 이유와 나이별로 셀 수 있고, 계측된 클라이언트는 특정 작업을 진행할지 판단할 수 있다. 그러나 하위 소프트웨어가 이 옵션을 이해하지 못하더라도 리졸버는 자체 결정 기록을 유지해야 한다.

인시던트 보고서는 EDE 코드를 그것을 만들어낸 갱신 시도와 캐시 항목에 연결해야 한다. 코드 3 이벤트의 원시 카운트만으로는 리졸버가 선의의 갱신을 했는지, 구성된 최대치 안에 머물렀는지, 짧은 TTL을 돌려줬는지, 이후 복구했는지 알 수 없다.

실행 중인 코드는 RFC가 로컬에 맡긴 정책 선택을 드러낸다

RFC 8767은 BIND 9.7.0용 초기 패치, 2011년부터 Akamai가 보고한 상용 사용, 이후 BIND 9.12 이상, Unbound, Knot Resolver의 지원을 서술한다. 이 역사가 중요한 이유는 메커니즘이 추상적인 가용성 논증만이 아니라 운영 경험에서 성장했기 때문이다.

그러나 이것이 균일한 동작을 증명하지는 않는다. 현재 Unbound 문서는 RFC 8767 동작이 1.23.0부터 기본 활성화라고 말한다. 클라이언트가 1.8초를 기다린 후 만료된 응답을 사용하거나 SERVFAIL을 반환하는 대신 사용하는 것, 1일 기본 최대 stale 수명, 30초 응답 TTL, 계속되는 해석 시도를 서술한다.

이 값들은 현재 구현 프로파일이다. IETF의 강제 사항이 아니며, 모든 Unbound 배포, 다른 소프트웨어, 이전 버전을 서술하지 않는다. 운영자는 값을 바꿀 수 있다. 제품 업그레이드는 기본값을 바꿀 수 있다. 기능 이름만으로 활성 런타임 선택을 증명할 수 없다.

여기서 실행 코드 우선성이 실용적으로 드러난다. 통제 검토는 소프트웨어와 버전, 실제 설정, 질의별 상태 전이, 결과로 나온 와이어 응답을 포착해야 한다. 건강한 권위적 경로, 타임아웃, SERVFAIL, 검증 실패, stale 기한 전 복구, 기한 후 복구, TTL 0 레코드를 테스트해야 한다. 문서는 가능한 동작을 서술할 뿐; 트레이스가 실제 발생한 동작을 보여준다.

Lawrence의 역할은 기여이지, 위임된 권위가 아니다

IETF Datatracker는 David C. Lawrence를 “tale” 핸들로 기록하고 RFC 3425, 7871, 8767, 8914를 나열한다. 현재 기록은 그를 Adaptive DNS Discovery 워킹그룹 의장, ICANN 이사회와의 IETF 연락자, DNS 및 인터넷 관련 디렉터리테의 검토자로도 나열한다.

ICANN의 현재 이사회 페이지는 David Lawrence를 2024년 11월 14일부터 IETF의 투표권 없는 연락자로 식별한다. 그의 약력은 RPI와 Usenet, UUNET, ISC의 BIND 재작성, Nominum, Akamai에서의 13년, 2010년 DNSSEC 루트 키 신뢰 커뮤니티 대표자 선출, 과거 DNS-OARC 이사회 임원, 현재 CVFiber 이사회 임원의 경력을 보여준다.

이 기록들은 DNS 구현, 표준, 제도적 연락에서 오랜 참여의 위치를 잡아준다. 이는 시간으로 한정되며, Lawrence를 serve-stale의 유일한 발명가로 만들지 않는다. RFC 8767에는 세 명의 저자가 있고, 더 넓은 구현자 경험과 IETF 합의를 반영한다. 그의 연락자 역할은 ICANN 이사회의 표결권이나 어떤 운영자의 리졸버 설정에 대한 통제권도 주지 않는다.

동일한 권위 규율이 캐시된 응답에도 적용된다. 유용한 사본은 원본이 되지 않고도 일시적 기능을 수행할 수 있다. 이름이 밝혀진 기여자는 집단적 메커니즘 정의에 도움을 줄 수 있지만, 그 운영자가 되지는 않는다.

복구를 증명할 수 있는 stale 응답 영수증 만들기

최소한의 결합된 기록은 캐시 항목으로 시작한다: 소유자 이름, 타입, 클래스, 원본 응답 출처, 원본 TTL, 삽입 및 만료 시각, 응답 데이터 해시, DNSSEC 상태. 이어서 최근 갱신 시도를 기록한다: 대상 서버, 전송 방식, 시간, 응답 또는 실패 분류, 이전 실패가 즉시 대체를 정당화했는지 여부.

다음은 결정 필드다: 구성된 최대 stale 수명, 계산된 자격 기한, 응답 시점의 나이, 클라이언트 대기 예산, 반환된 TTL, EDE 코드, 정책 예외. 별도의 갱신 기록이 다음 시도와 백오프를 보여준다.

닫는 영수증은 권위적 복구다: 첫 사용 가능한 신선 응답, 검증 결과, 새 데이터 해시, 설치 시각, 은퇴된 stale 항목, 애플리케이션에 보이는 결과. 새 권위적 응답이 다르다면, 기록은 클라이언트가 이전 값을 받았다는 증거를 조용히 덮어쓰는 대신 그 전이를 보존해야 한다.

이것이 캐시 안에서의 대장부-문지기 구분이다. 리졸버는 이름의 소유권을 주장하지 않고도 서비스를 가용하게 유지할 수 있다. 통제는 출처, 나이, 원본 복구가 계속 보이면 성공한다. 오래된 응답이 클라이언트가 계속 응답을 받았다는 이유만으로 설명 없는 영구 대체물이 되면 실패한다.

영구 규칙은 “만료는 무용함을 뜻한다”도 “가용성이 이긴다”도 아니다. 더 좁다: 만료된 응답은 그것을 권위에 종속되게 유지하는 모든 경계가 증명 가능한 동안에만 연속성을 운반할 수 있다.

출처