증상문제 59개· 검수 문제 4개

DNS Resolution Failure

‘DNS Resolution Failure’ 증상으로 나타나는 장애 문제 59개를 모았습니다.

모든 문제 59개

NETWORK-300DNS resolver 클러스터는 계속 응답하는데 방화벽 갱신 하나가 큰 DNSSEC 서명 응답의 TCP 폴백 경로만 차단 (failover 리허설 중)대부분의 조회는 되고 더 큰 서명 응답이 숨은 프로토콜 공백을 드러냅니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Network중급17분ProSECURITY-306DNS 기반 보안 통제가 새 조회는 차단하는데 오래된 resolver 캐시가 같은 host에 대해 이전 응답을 계속 서빙 (failover 리허설 중)통제는 이제 맞는데 캐시 계층 하나가 아직 어제의 판단을 신뢰합니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Security중급17분ProK8S-300headless Service는 모든 pod 주소를 주는데 클라이언트 라이브러리가 축소 후에도 오래된 캐시 부분집합에서 무작위 선택 (failover 리허설 중)서비스 디스커버리는 정확한데 클라이언트가 더는 존재하지 않는 endpoint로 계속 연결합니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Kubernetes중급17분ProK8S-258stubDomain이 내부 이름은 제대로 전달하는데 노드 로컬 DNS의 negative 캐시가 새로 만들어진 서비스를 가림 (failover 리허설 중)전달 체인은 맞는데 계층 하나가 서비스 수명주기보다 오래 실패를 기억합니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Kubernetes중급17분ProSECURITY-429새 질의에는 DNS sinkhole이 작동하는데 재귀 resolver 하나가 이전 정책 시기의 응답을 계속 서빙 (통제된 폐기 훈련 중)차단 정책은 이제 맞는데 resolver 기억이 계속 옛 결정을 반영합니다. 주 구성 요소는 계속 트래픽을 서빙하는데, 폐기 훈련이 제거 대상에 대한 잠복 의존성을 드러냅니다.Security중급17분ProNETWORK-216작은 DNS 조회는 되는데 큰 응답용 TCP 폴백이 계속 차단 (failover 리허설 중)응답 크기가 프로토콜 경로를 바꾸기 전까지는 해석이 대체로 정상으로 보입니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Network중급17분ProK8S-180클러스터 DNS는 맞는데 클라이언트 런타임 하나가 첫 응답을 무기한 캐시 (failover 리허설 중)서비스 디스커버리 계층은 갱신되는데 그것을 쓰는 라이브러리는 아무것도 안 바뀐 것처럼 동작합니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Kubernetes중급17분ProK8S-499NetworkPolicy가 애플리케이션 경로는 허용하는데 node-local DNS 포워딩이 규칙이 기대한 것과 다른 source 신원을 사용앱 트래픽은 허용되는데 이름 해석이 실패합니다 — helper 경로가 더는 정책 전제와 맞지 않습니다. 명시 설정은 맞아 보이는데 상속된 정책이 정리된 계층에서 다르게 해석됩니다.Kubernetes중급18분ProK8S-501NetworkPolicy가 애플리케이션 경로는 허용하는데 node-local DNS 포워딩이 규칙이 기대한 것과 다른 source 신원을 사용 (구 경로 종료 훈련 중)앱 트래픽은 허용되는데 이름 해석이 실패합니다 — helper 경로가 더는 정책 전제와 맞지 않습니다. 주 구성 요소는 계속 트래픽을 서빙하는데, 폐기 훈련이 제거 대상에 대한 잠복 의존성을 드러냅니다.Kubernetes중급18분ProK8S-497NetworkPolicy가 애플리케이션 경로는 허용하는데 node-local DNS 포워딩이 규칙이 기대한 것과 다른 source 신원을 사용 (테넌시 경계 재설계 후)앱 트래픽은 허용되는데 이름 해석이 실패합니다 — helper 경로가 더는 정책 전제와 맞지 않습니다. 기능 경로는 살아 있는데 숨은 의존성 하나가 공유·격리 자원 사이의 옛 경계를 계속 전제합니다.Kubernetes중급18분ProNETWORK-483resolver는 캐시에서 응답하는데 DNS64나 split-horizon 뷰 하나가 authoritative 경로에서만 바뀌어 새 클라이언트가 즉시 실패 (구 경로 종료 훈련 중)warm 클라이언트는 정상으로 보이고 cold 클라이언트가 설계가 틀어졌음을 드러냅니다. 주 경로로는 서비스가 계속 되고, 옛 구성 요소가 완전히 빠질 때만 의존성 하나가 실패합니다. 주 구성 요소는 계속 트래픽을 받지만, 폐기 훈련이 제거 대상에 대한 잠복 의존성을 드러냅니다.Network중급18분ProSECURITY-430새 질의에는 DNS sinkhole이 작동하는데 재귀 resolver 하나가 이전 정책 시기의 ECS·지역 기반 응답을 계속 서빙차단 정책은 이제 맞는데 resolver 기억이 계속 옛 결정을 반영합니다. 플랫폼은 계속 온라인인데 자동화나 런북 전제 하나가 소유권 이전을 견디지 못했습니다.Security중급18분ProSECURITY-426새 질의에는 DNS sinkhole이 작동하는데 재귀 resolver 하나가 이전 정책 시기의 응답을 계속 서빙 (지역 복원력 훈련 중)차단 정책은 이제 맞는데 resolver 기억이 계속 옛 결정을 반영합니다. 콜드 스타트 상태에서 의존성 경로를 다시 구성해야 할 때까지 문제가 숨어 있었습니다.Security중급18분ProK8S-557NetworkPolicy가 애플리케이션 경로는 허용하는데 node-local DNS 포워딩이 규칙이 기대한 것과 다른 source 신원을 사용 (경계 강화 작업 중)앱 트래픽은 허용되는데 이름 해석이 실패합니다 — helper 경로가 더는 정책 전제와 맞지 않습니다. 눈에 보이는 흐름은 멀쩡한데 의존성 하나가 강화 이전의 느슨한 경계 모델을 계속 전제합니다.Kubernetes중급19분ProNETWORK-480resolver는 캐시에서 응답하는데 DNS64나 split-horizon 뷰 하나가 authoritative 경로에서만 바뀌어 새 클라이언트가 즉시 실패 (콜드 스타트 복구 리허설 중)warm 클라이언트는 정상으로 보이고 cold 클라이언트가 설계가 틀어졌음을 드러냅니다. 복원력 훈련이 대체 경로를 켜기 전까지는 평상시 트래픽이 정상으로 보였고, 기댈 warm 상태 없이 의존성 경로를 처음부터 다시 세워야 할 때 비로소 드러났습니다.Network중급19분ProSECURITY-490새 질의에는 DNS sinkhole이 작동하는데 재귀 resolver 하나가 이전 정책 시기의 오래된 ECS·지역 응답을 계속 서빙차단 정책은 이제 맞는데 resolver 기억이 계속 옛 결정을 반영합니다. 서비스는 계속 온라인인데 자동화나 런북 전제 하나가 팀 인계와 함께 깔끔히 옮겨지지 않았습니다.Security중급19분ProNETWORK-542resolver는 캐시에서 응답하는데 DNS64나 split-horizon 뷰 하나가 authoritative 경로에서만 바뀌어 새 클라이언트가 즉시 실패 (강화된 통제 배포 후)warm 클라이언트는 정상으로 보이고 cold 클라이언트가 설계가 틀어졌음을 드러냅니다. 워크로드 설정은 그대로지만, 갱신된 플랫폼 기준선이 하위 계층 의존성 하나를 더 엄격하게 해석합니다.Network중급20분ProNETWORK-599resolver는 캐시에서 응답하는데 DNS64나 split-horizon 뷰 하나가 authoritative 경로에서만 바뀌어 새 클라이언트가 즉시 실패 (격리 경계 재설정 후)warm 클라이언트는 정상으로 보이고 cold 클라이언트가 설계가 틀어졌음을 드러냅니다. 겉보기 워크플로는 그대로지만, 숨은 의존성 하나가 아직 강화 작업 이전의 느슨한 공유·격리 경계를 가정합니다.Network중급20분ProNETWORK-012Anycast DNS 전환 뒤 특정 지역에서만 오래된 IP를 계속 받는 문제전역 전환은 끝났지만 캐시와 지역별 리졸버 차이 때문에 일부 사용자만 구버전 엔드포인트로 향하는 상황입니다.Network중급23분Pro