프록시와 DNS 서버를 같은 Docker 호스트에서 실행한다고 해서 두 서비스의 DNS 경로가 연결되지는 않습니다. 중요한 것은 세 가지 별개의 관계입니다.

  • 네트워크 도달성. 별도의 Compose 프로젝트는 보통 별도의 기본 네트워크를 가집니다. 서비스를 하나의 프로젝트 안에서든, 프로젝트 간에 명시적으로 공유한 네트워크를 통해서든 적절한 공유 네트워크에 배치하십시오.
  • 서비스 검색. 사용자 정의 Docker 네트워크의 내장 DNS는 컨테이너 이름을 확인할 수 있습니다. 그래서 애플리케이션이 이웃을 발견할 수는 있지만, 그 이웃을 자동으로 자신의 DNS 리졸버로 선택하지는 않습니다.
  • 리졸버 선택. 프록시 컨테이너 내부에서 사용하는 리졸버를 확인하십시오. Compose의 dns 필드는 DNS 서버 주소를 받습니다. 애플리케이션에서 확인되는 dns.local 같은 이름이 그 필드에 유효한 값이 되는 것은 아닙니다.

질의를 프록시 컨테이너에서 설정된 리졸버 주소까지 추적하십시오. 그 주소에 경로와 DNS 리스너가 있는지 확인하십시오. 호스트 포트 53을 공개하면 호스트 측 접근 경로가 생기지만, 컨테이너에 그것을 사용하라고 알려 주지는 않습니다. 같은 네트워크를 공유하는 컨테이너는 대신 직접 통신할 수 있습니다.

설정이 DNS 컨테이너의 주소를 참조한다면 호환되는 IPAM 설정 아래에서 그 주소를 안정적으로 유지하십시오. 어제 컨테이너에서 복사한 동적 할당 주소는 다시 만들 때 실패할 수 있습니다. 리졸버의 업스트림 경로도 확인하십시오. 응답 없는 질의를 자기 자신에게 되돌려 보내면 도달할 수 없는 리졸버와는 다른 장애가 생깁니다.

마지막으로 목적지를 누가 확인하는지 파악하십시오. CONNECT 이름을 확인하는 HTTP 프록시는 이 컨테이너 경로를 사용할 수 있지만, 로컬에서 확인하는 SOCKS 클라이언트는 그렇지 않을 수 있습니다. 호스트에서의 조회는 호스트의 경로를 증명할 뿐 프록시 프로세스의 경로를 증명하지 않습니다.

관련 글