새 도메인 레코드를 만들었는데 일부 클라이언트는 계속 없다고 합니다. DNS의 음성 캐시는 어떻게 작동하나요?
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
DNS는 성공 응답뿐 아니라 이름이나 유형이 없다는 부정 응답도 일정 시간 캐시할 수 있습니다. 레코드를 만들었다고 이미 저장된 부재 판단이 즉시 사라지는 것은 아닙니다.
동작 원리와 전제
NXDOMAIN과 특정 유형의 데이터 부재를 구분하고 authoritative 응답·재귀 resolver·OS·앱 캐시에서 어디에 남았는지 확인합니다. 음성 캐시 TTL은 관련 SOA 정보와 구현 규칙의 영향을 받습니다. 일반 레코드 TTL만 낮추면 모든 부재 캐시가 즉시 해제된다고 가정하지 않습니다.
선택과 실패 처리
배포 전에 도메인을 준비하고 resolver별 질의 결과와 TTL을 확인합니다. 무조건 DNS 서버를 바꾸는 것보다 실제 캐시 계층을 찾습니다. SERVFAIL 같은 실패의 재시도·캐시 동작도 단순한 미존재와 구분합니다.
구체적인 사례와 검증
배포 직전 새 호스트를 미리 조회해 NXDOMAIN을 캐시한 클라이언트는 레코드 생성 직후에도 실패할 수 있습니다. 이 경우 authoritative 서버에 직접 질의하면 새 값이 보이지만 재귀 resolver 경로에서는 부정 응답이 남습니다. 어느 계층에서 확인했는지와 TTL을 함께 기록해야 DNS 설정이 틀린 것과 전파·캐시를 구분할 수 있습니다. 앱이 자체적으로 실패 결과를 캐시하면 DNS TTL이 끝난 뒤에도 장애가 이어질 수 있습니다. 이름 조회를 해결한 뒤 TLS 이름·인증서·서비스 readiness가 맞는지도 확인합니다. DNS 성공 하나를 전체 서비스 준비 완료로 보고하지 않습니다.
부재 조회 후 생성, 레코드 유형 추가, 여러 resolver와 앱 재시작을 시험합니다. DNS가 복구돼도 기존 연결 풀과 앱 실패 캐시가 남을 수 있습니다. 이름 조회의 최신성과 서비스 준비 상태를 별도 관찰하겠습니다.
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- 핵심 구분: DNS는 성공 응답뿐 아니라 이름이나 유형이 없다는 부정 응답도 일정 시간 캐시할 수 있습니다.
- 선택 조건: 배포 전에 도메인을 준비하고 resolver별 질의 결과와 TTL을 확인합니다.
- 검증 기준: 부재 조회 후 생성, 레코드 유형 추가, 여러 resolver와 앱 재시작을 시험합니다.
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- 레코드 생성 즉시 모든 기존 부정 캐시가 사라진다고 한다.
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
- 이름 조회가 갱신돼도 기존 연결이 남을 때 이전 서버의 종료 시점을 어떻게 판단하나요?
- 연결 재사용을 늘리면서 유휴 종료·목적지 변경·하위 용량을 어떻게 함께 관리하나요?
- 지속 장애의 재시도를 차단한 뒤 제한된 시험 요청으로 언제 복귀하나요?
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.