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

DNS Resolution Failure

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

모든 문제 59개

NETWORK-007재부팅 이후 NAT egress가 막히는 ip_forward 설정 누락 문제일시 수정으로는 해결됐지만 재부팅 후 다시 터지는 커널 네트워크 설정 문제를 다룹니다.Network중급22분무료 NETWORK-100Anycast DNS는 계속 도달되는데 AXFR 정책 변경 후 사이트 하나가 오래된 zone 데이터를 서빙전역적으로는 서비스가 떠 있어 보이는데 응답이 갈립니다 — 새 정책 아래에서 anycast 사이트 하나가 zone transfer를 받지 못하게 됐습니다.Network고급18분Pro SECURITY-027레거시 hostname 하나로 egress 프록시 우회가 계속 가능대부분의 아웃바운드 트래픽은 이제 보안 경로를 쓰는데, 간과된 레거시 이름 하나가 여전히 기대한 통제 지점을 우회해 해석됩니다.Security고급27분Pro CICD-026승격 파이프라인이 이전 커밋의 오래된 이미지를 배포승격 단계가 쓰는 artifact 참조는 맞아 보이는데 레지스트리 정리 후 더 오래된 이미지 digest로 해석됩니다.CI/CD고급29분Pro NETWORK-062MLAG peer link는 정상인데 orphan VLAN이 허용되지 않아 ARP가 랙 하나를 블랙홀chassis 쌍은 계속 살아 있는데 랙의 절반이 게이트웨이를 찾지 못합니다 — 해당 VLAN이 peer 경로에 허용된 적이 없습니다.Network고급23분Pro SECURITY-148DNS 방화벽이 알려진 악성 도메인을 차단하는데 내부 resolver가 최근 차단된 host 하나에 대해 계속 오래된 긍정 캐시 응답을 반환정책은 이제 맞는데 캐시된 해석 경로가 어제의 신뢰 판단을 보존합니다.Security고급16분Pro SECURITY-137split-horizon DNS가 도메인 소유 확인에 필요한 외부 TXT 레코드를 빠뜨려 SSO 전환이 공개 쪽에서 끝내 검증되지 않음내부 테스트는 통과하는데 네트워크 밖 컨트롤 플레인이 필요한 증거를 보지 못합니다.Security고급16분Pro LINUX-112라우팅 도메인이 엉뚱한 링크에 붙어 systemd-resolved split DNS가 내부 도메인을 공용 resolver로 보냄이름은 내부에 있는데 질의가 바깥으로 새어 나갑니다 — resolver 정책이 앱이 실제로 쓰는 인터페이스와 다른 인터페이스에 묶여 있습니다.Linux고급17분Pro SECURITY-204새로 차단한 도메인이 오래된 resolver 캐시 상태로 계속 도달 가능 (failover 리허설 중)통제는 이제 맞는데 캐시가 어제의 신뢰 판단을 그대로 보존합니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Security고급17분Pro SECURITY-258DNSSEC 서명된 공개 zone은 검증되는데 내부 split-horizon 사본이 서명되지 않은 하위 레코드를 계속 서빙 (failover 리허설 중)외부 신뢰는 정상인데 내부 신뢰 전제가 더는 그것과 맞지 않습니다. failover 리허설에서 standby나 대체 경로가 활성화되기 전까지는 평상시 트래픽이 문제를 감췄습니다.Security고급18분Pro SECURITY-117레지스트라에서는 DNSSEC이 검증되는데 CDS·CDNSKEY 자동화가 멈춰 자식 zone이 서서히 어긋남오늘은 검증이 통과하는데 위임 경로가 실패 쪽으로 늙어가고 있습니다 — 상위 갱신 자동화가 조용히 멈췄습니다.Security고급18분Pro NETWORK-030blue-green 전환이 webhook 콜백 허용목록을 빠뜨림새 스택이 라이브인데 콜백 제공자 하나가 아직 옛 주소를 가리킵니다 — 허용 목록과 DNS 전환이 어긋나 있습니다.Network중급19분Pro K8S-025네임스페이스 간 DNS 조회가 디버그 pod에서는 되고 앱 pod에서 안 됨빠른 디버그 셸에서는 이름이 해석되는데 워크로드 컨테이너는 실패합니다 — search 도메인과 런타임 이미지가 다릅니다.Kubernetes중급20분Pro NETWORK-022resolver 하나가 새 TTL을 무시해 내부 DNS가 옛 대상으로 해석대부분의 클라이언트는 새 목적지를 받아들이는데 일부가 오래된 IP에 남습니다 — resolver 동작이 일관되지 않습니다.Network중급21분Pro K8S-134노드 로컬 DNS 캐시가, 잠시 뒤 만들어진 Service에 대해 NXDOMAIN을 서빙하고 노드 하나가 롤아웃 내내 그 잘못된 응답을 유지이제 Service는 존재하는데 resolver 경로 하나가 계속 이전 negative 캐시 결과를 신뢰합니다.Kubernetes중급15분Pro NETWORK-150DNS resolver 클러스터는 내부적으로 응답하는데 모니터링 probe가 TCP로만 질의하고 방화벽 변경으로 큰 레코드의 폴백 응답이 차단됨응답이 커져 probe가 더는 닿지 않는 프로토콜 경로가 필요해지기 전까지는 대부분의 조회가 괜찮아 보입니다.Network중급16분Pro K8S-144headless Service가 pod A 레코드를 제대로 반환하는데 Java 클라이언트 하나가 첫 응답을 영영 캐시해 확장 후에도 분산하지 않음클러스터 DNS는 정확한데 라이브러리 하나의 조회 동작이 의도한 설계를 무력화합니다.Kubernetes중급16분Pro K8S-381NetworkPolicy가 애플리케이션 경로는 허용하는데 node-local DNS 포워딩이 규칙이 기대한 것과 다른 source 신원을 사용 (단계적 폐기 중)앱 트래픽은 허용되는데 이름 해석이 실패합니다 — helper 경로가 더는 정책 전제와 맞지 않습니다. 주 경로로는 서비스가 계속 되고, 옛 구성 요소가 완전히 빠질 때만 의존성 하나가 실패합니다.Kubernetes중급16분Pro NETWORK-363resolver는 캐시에서 응답하는데 DNS64나 split-horizon 뷰 하나가 authoritative 경로에서만 바뀌어 새 클라이언트가 즉시 실패 (단계적 폐기 중)warm 클라이언트는 정상으로 보이고 cold 클라이언트가 설계가 틀어졌음을 드러냅니다. 주 경로로는 서비스가 계속 되고, 옛 구성 요소가 완전히 빠질 때만 의존성 하나가 실패합니다.Network중급16분Pro SECURITY-369새 질의에는 DNS sinkhole이 작동하는데 재귀 resolver 하나가 이전 정책 시기의 응답을 계속 서빙 (단계적 폐기 중)차단 정책은 이제 맞는데 resolver 기억이 계속 옛 결정을 반영합니다. 주 경로로는 서비스가 계속 되고, 옛 구성 요소가 완전히 빠질 때만 의존성 하나가 실패합니다.Security중급16분Pro