프라이빗 DNS는 VPC 안에서는 동작하지만 VPN으로는 동작하지 않는다
EC2 안에서는 확인되지만 VPN으로는 확인되지 않는 프라이빗 이름은 리졸버 경로 문제입니다. 영역 레코드를 수정하기 전에 실패의 형태를 읽으세요.
프라이빗 이름이 EC2 인스턴스에서는 확인되지만 VPN으로 연결한 노트북에서는 확인되지 않고, 콘솔에서는 영역이 올바르게 보입니다. 첫 반응은 레코드를 고치는 것이지만, 그것은 거의 문제가 아닙니다. 레코드는 누군가에게 응답하고 있으며, 다만 당신의 노트북에는 응답하지 않습니다. 두 호출자의 차이는 어느 리졸버에 묻는지, 그리고 그 리졸버에 VPC의 DNS 뷰로 들어가는 지원되는 경로가 있는지입니다.
레코드가 존재함을 증명하는 것으로 시작하고, 남은 시간은 질의 경로에 씁니다. 이 둘은 별개의 시스템이고 실패하는 형태도 다릅니다.
무엇이든 바꾸기 전에 실패의 형태를 읽으세요
세 가지 결과는 서로 다른 세 가지를 뜻하며, 클라이언트가 실제로 사용하는 리졸버를 대상으로 그 이름에 대해 dig를 실행하면 질의 하나로 그것을 구분할 수 있습니다.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
시간 초과는 네트워크에 대한 진술입니다. NXDOMAIN은 DNS 뷰에 대한 진술입니다. 공개 주소 응답은 정책에 대한 진술입니다. 시간 초과가 있는 상태에서 영역 레코드를 고치면 이 사건에서 유일하게 쓸모 있는 증거를 버리게 됩니다.
VPC의 플러스 둘 주소가 원격 리졸버가 아닌 이유
CIDR 플러스 둘 주소는 VPC 내부 리소스를 위한 로컬 서비스입니다. 온프레미스 네트워크나 다른 VPC의 DNS 서버에서 오는 질의를 그 주소로 직접 전달하는 것은 지원되지 않으며 불안정한 결과를 낳을 수 있다고 AWS는 문서화합니다.
그렇다고 해서 실험이 절대 동작하는 것처럼 보이지 않는다는 뜻은 아니며, 그 동작이 헬프데스크 스크립트에 넣을 수 있는 계약이 아니라는 뜻입니다. 지원되는 방향은 인바운드 Resolver 엔드포인트입니다. VPC 안에 있고, 당신이 통제하는 네트워크에서 도달할 수 있으며, AWS 외부에서 오는 질의를 받아들이는 주소 쌍입니다.
깔끔하게 실패하는 순서로 경로를 만드세요
세 개의 홉이 있어야 하고, 각각은 나름의 실패 방식을 가집니다.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addresses포워더는 VPN을 통해 엔드포인트 주소로 가는 경로가 필요하고, 돌아오는 경로도 동작해야 합니다. 포트 53의 전통적인 DNS에서 엔드포인트는 UDP와 TCP로 응답하므로 두 프로토콜을 모두 허용해야 하고, 둘 다 중간의 어떤 상태 검사도 통과해야 합니다.
그다음 DNS 뷰를 따로 확인하세요. 프라이빗 호스팅 영역은 연결된 VPC에만 보이거나, 의도적으로 구성한 공유 방식으로만 보입니다. 도달 가능한 엔드포인트가 있다고 해서 모든 프라이빗 영역이 그 해석 컨텍스트에서 확인 가능해지는 것은 아닙니다.
아웃바운드 엔드포인트는 반대 방향을 담당하며 당신의 노트북에서 들어오는 질의에는 응답하지 않습니다.
양쪽 끝에서 검증하세요
클라이언트에서 포워더로 질의하고, 그다음 포워더에서 엔드포인트로 질의하세요. 클라이언트가 실패하는데 포워더가 성공한다면 그 둘 사이에 간극이 있습니다.
둘 다 실패하면 엔드포인트의 보안 정책과 그것이 실제로 보는 원본 주소를 확인하세요. NAT 뒤의 포워더는 노트북의 VPN 주소가 아니라 NAT 주소를 제시하므로, 그 차이만으로도 질의가 버려질 수 있습니다. 둘 다 성공하는데 애플리케이션이 여전히 실패한다면, 애플리케이션이 테스트한 것과 다른 리졸버를 쓰고 있을 수 있습니다.
공개와 프라이빗 이름 공간은 의도적으로 분리해 두세요. Split DNS는 당신이 구성하는 정책이며, 한 번의 조회가 우연히 데이터를 반환한 부작용이 아닙니다.
내가 하지 않을 일
한 번의 조회를 통과시키기 위한 NAT 규칙을 추가하고 그것을 설계라고 부르지는 않겠습니다.
한 번의 테스트가 레코드를 반환했다고 해서 모든 원격 클라이언트를 플러스 둘 주소로 돌리지는 않겠습니다. 그리고 포워더 하나에만 접근이 필요할 때 엔드포인트의 보안 정책을 VPN 풀 전체로 넓히지도 않겠습니다. 조직이 이미 VPC 안에서 승인된 포워더를 운영하고 있다면, 당신이 추가하는 두 번째 엔드포인트가 바로 아무도 문서화하지 않는 그것이므로 그 설계를 먼저 읽으세요.