호스트에서는 DNS 확인이 작동하지만 컨테이너 내부에서는 실패하는 이유

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Why Does DNS Resolution Work on the Host but Fail Inside a Container? - Zima Store Online

호스트 DNS는 작동하지만 컨테이너 DNS가 실패할 수 있습니다. 컨테이너가 다른 리졸버 경로, 네임스페이스, 방화벽 경로 또는 Docker 포워딩 상태를 사용하기 때문입니다.

홈 서버에서 호스트는 라우터, Pi-hole 또는 VPN 리졸버에 직접 질의할 수 있지만, 브리지 네트워크의 컨테이너는 Docker의 내장 리졸버나 복사된 resolv.conf를 통해 요청을 보낼 수 있습니다. 가장 빠른 진단 방법은 먼저 IP 주소를 테스트한 다음, 문제가 발생한 컨테이너에서 각 리졸버에 명시적으로 질의하는 것입니다. 이렇게 하면 DNS 실패를 일반적인 외부 연결 문제와 혼동하지 않을 수 있습니다.

DNS 실패와 일반적인 네트워크 실패를 구분하기

문제가 발생한 컨테이너에서 알려진 외부 IP와 사용하려는 DNS 서버의 IP 주소를 테스트한 후 호스트 이름을 테스트하세요. 라우팅, 패킷 손실, TCP 및 UDP 포트 53에 연결할 수 있는지도 기록하세요.

Manjaro 컨테이너 사례는 반대되는 상황을 보여 줍니다. 직접 IP 트래픽도 실패했기 때문에 문제가 DNS보다 광범위하다는 사실이 입증되었습니다. 이 직접 IP 연결 테스트는 리졸버 변경으로 손상된 브리지, NAT 또는 방화벽 경로를 가리는 일을 방지합니다.

IP 연결이 실패한다면 먼저 컨테이너 네트워크를 복구하세요. IP 연결은 되지만 이름 확인이 실패한다면 리졸버 구성과 질의 경로를 계속 확인하세요.

컨테이너 내부의 리졸버 구성 확인하기

컨테이너 내부에서 /etc/resolv.conf를 읽고 호스트의 설정과 비교하세요. 네임서버 주소, 검색 도메인, 옵션, 네트워크 모드, 컨테이너를 다시 만들었을 때 파일이 변경되는지 확인하세요.

OpenMediaVault 사례에서는 런타임 업데이트 후 Docker의 내장 127.0.0.11 리졸버를 통한 컨테이너 이름 확인이 실패했습니다. 이 내장 리졸버 경로는 호스트에서 성공한 이름 확인 경로와 다를 수 있습니다.

실행 중인 컨테이너 내부에서 생성된 파일을 영구적으로 편집하지 마세요. 컨테이너를 다시 만들어도 유지되도록 의도한 DNS 서버와 검색 도메인은 Compose 또는 플랫폼 구성에 지정하세요.

Docker DNS와 업스트림 리졸버를 별도로 질의하기

Docker의 내장 리졸버, 라우터 또는 로컬 DNS 서버, 그리고 정책상 허용되는 경우 알려진 외부 리졸버에 동일한 이름 확인을 요청하세요. 시간 초과, 거부, NXDOMAIN, 반환된 주소를 비교하세요.

TrueNAS 커뮤니티 사례에서는 다른 호스트 트래픽은 정상적으로 작동했지만, 라우터 액세스 프로필이 컨테이너 요청을 차단하여 컨테이너에서만 DNS가 실패한 것으로 확인되었습니다. 결정적인 관찰 결과는 잘못된 호스트 이름이 아니라 컨테이너 경로의 DNS 차단이었습니다.

직접 업스트림 질의는 작동하지만 내장 리졸버가 실패한다면 Docker의 리졸버와 네트워크 상태를 다시 시작하거나 복구하세요. 모든 DNS 서버에서 시간 초과가 발생한다면 포트 53의 라우팅, 방화벽, VPN 및 응답 트래픽을 점검하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

로컬 DNS 루프와 잘못된 내부 응답 확인하기

컨테이너가 동일한 호스트, 다른 컨테이너 또는 리버스 프록시를 통해 다시 확인되는 호스트 이름에 DNS 질의를 보내고 있는지 확인하세요. 모든 성공적인 이름 확인이 올바르다고 가정하지 말고 실제 응답을 캡처하세요.

Traefik 커뮤니티 사례에서는 한 컨테이너가 사용자 지정 도메인을 의도한 피어가 아니라 자기 자신으로 확인하는 문제가 발견되었습니다. 이 잘못된 컨테이너 측 DNS 응답은 기본적인 이름 확인 테스트를 통과했지만 API 연결은 여전히 실패하게 만들었습니다.

동일한 네트워크의 컨테이너 간 트래픽에는 서비스 이름을 사용하고, 의도한 경우에만 공용 호스트 이름에 분할 DNS를 사용하세요. 로컬 종속성에 접근하기 위해 컨테이너가 공용 프록시를 거치는 헤어핀 경로는 해당 경로를 명시적으로 테스트한 경우가 아니라면 피하세요.

UDP 응답, NAT 및 네트워크 격리 확인하기

컨테이너 인터페이스와 호스트 브리지에서 포트 53 트래픽을 캡처하세요. 질의가 전송되고, 리졸버가 이를 수신하며, 클라이언트가 예상하는 주소에서 응답이 돌아오는지 확인하세요.

Pi-hole 사용자들은 예상하지 못한 변환 소스에서 응답이 돌아와 동일한 호스트의 컨테이너 질의가 시간 초과되는 사례를 보고했습니다. 이 예상하지 못한 DNS 응답 소스는 응답 경로 문제와 응답하지 않는 리졸버를 구분하는 데 도움이 됩니다.

요청과 응답이 서로 다른 Docker 네트워크를 통과한다면 모든 서비스를 호스트 네트워킹으로 옮기지 말고 올바른 공유 네트워크 또는 라우트를 추가하세요. 브리지 서브넷을 호스트 주소와 다르게 처리할 수 있는 방화벽 영역과 VPN 정책도 확인하세요.

네트워크 상태를 다시 만들고 수정 사항 검증하기

리졸버, 방화벽 또는 네트워크 정의를 수정한 후 의도한 네트워크에서 테스트 컨테이너 하나를 다시 만들고 IP, 직접 리졸버, 내장 리졸버, 서비스 이름 및 공용 이름 테스트를 반복하세요.

ZimaSpace의 주소 문제와 이름 문제 구분하기 가이드는 호스트 측 진단 경계를 이해하는 데 도움이 됩니다.

DNS 구성이 컨테이너 재생성과 재부팅 후에도 유지되고, 내부 서비스 이름과 승인된 공용 이름이 의도한 주소를 반환하며, 애플리케이션 트래픽이 동일한 네트워크 경로를 통해 정상적으로 전달될 때에만 문제가 해결된 것입니다. Docker 업데이트 후에만 문제가 다시 발생한다면 런타임 회귀의 경계 지점으로 사용할 수 있도록 버전과 데몬 로그를 보존하세요.