피드로 돌아가기
Why Lowering ndots Breaks Alpine Pods (But Not Debian) — A Deep Dive into glibc vs musl Resolvers
Dev.toDev.to
Infrastructure

musl libc의 Resolver 특성으로 인한 Alpine Pod DNS 장애 분석

Why Lowering ndots Breaks Alpine Pods (But Not Debian) — A Deep Dive into glibc vs musl Resolvers

Eunji2026년 5월 2일11advanced

Context

Kubernetes 기본 설정인 ndots:5와 3개의 Search List 조합으로 인해 외부 도메인 조회 시 최대 5회의 DNS 쿼리가 발생하는 Query Amplification 문제 발생. DNS 성능 최적화를 위해 ndots 값을 낮추는 시도가 이루어졌으나, 이미지 베이스 libc 구현체에 따라 내부 서비스 해석 결과가 달라지는 현상 발견.

Technical Solution

  • DNS Resolution 결정 주체가 CoreDNS가 아닌 Pod 내 libc Resolver임을 식별
  • glibc 기반 배포판(Debian, Ubuntu 등)의 경우 dots ≥ ndots 상황에서 최초 쿼리 실패 시 Search List를 순회하는 Fallback 메커니즘 작동
  • musl libc 기반 배포판(Alpine)의 경우 dots ≥ ndots 시 최초 쿼리 실패 후 Search List 순회를 생략하는 엄격한 구현 방식 채택
  • ndots 값을 낮춤에 따라 더 많은 내부 서비스 이름이 dots ≥ ndots 조건에 해당하며 musl 환경에서 Resolution 실패 유발
  • 해결책으로 trailing dot을 포함한 FQDN 사용 또는 glibc 기반 이미지로의 전환 설계 제시

1. Alpine 이미지 사용 시 ndots 변경 전 내부 서비스 해석 테스트 수행

2. DNS 성능 최적화가 필요할 경우 ndots 변경보다 NodeLocal DNSCache 도입 우선 검토

3. 환경에 무관한 안정적 해석을 위해 내부 서비스 호출 시 trailing dot을 포함한 FQDN 적용

원문 읽기