프라이빗 Route 53 영역이 공용 이름에 NXDOMAIN을 반환하는 이유

프라이빗 Route 53 영역은 공용 레코드와 병합되는 대신 이름에 대한 응답을 대체하며, 그래서 사람들은 최악의 순간에 당황합니다. 내부 레코드를 하나 추가합니다. 대상은 api.example.net 이고, 이를 담을 프라이빗 영역은 example.net 입니다. 그 영역을 VPC에 연결하면 이 상위 이름 아래의 다른 모든 이름은 이제 프라이빗 영역에서만 응답합니다. 어제까지 www.example.net 에 접근할 수 있었던 클라이언트는 오늘 부정 응답을 받습니다. 아래 설명은 그 실패한 쿼리에서 시작해 응답한 영역으로 바깥쪽으로 나아갑니다.

콘솔이 아니라 쿼리에서 시작하세요

문제를 보고한 클라이언트에서 오류를 재현하고 정확한 이름과 레코드 유형을 기록하세요. A 에서 실패하는 이름도 AAAA 에서는 확인될 수 있으며, 캐시된 이름을 다시 시도하는 브라우저는 둘 중 무엇이 깨졌는지 감춥니다. 쿼리를 두 번 실행하세요. 한 번은 클라이언트가 실제로 사용하는 리졸버를 통해, 한 번은 그것을 우회하는 추적과 함께.

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

중요한 것은 두 번째 명령입니다. 상태 줄과 authority 섹션이 응답을 만든 영역을 알려 주므로, 프라이빗 영역의 부정 응답을 타임아웃, 차단된 포트, 쿼리를 받지 못한 리졸버와 구분할 수 있습니다. resolvectl 는 어느 상위 서버에 질의했는지 보여 주며, 이는 VPN이 밀어 넣었다고 가정한 리졸버가 아닌 경우가 많습니다.

추적한 쿼리가 공용 주소를 반환하고 일반 쿼리는 그렇지 않다면, 공용 레코드는 온전하고 프라이빗 뷰가 응답하는 것입니다. 이 한 번의 비교가 이 페이지의 나머지 중 어느 절반이 해당하는지를 결정합니다.

어느 영역이 응답했는지 읽기

응답에 NXDOMAIN 이 포함되고 authority 섹션에 프라이빗 영역의 SOA가 있다면, 그것은 해당 영역의 확정 응답이며 조회 실패가 아닙니다. Route 53 Resolver는 이름이 일치했기 때문에 프라이빗 호스팅 영역을 선택했고, 이어서 요청된 유형의 레코드를 찾지 못했으며, 문서화된 동작은 질문을 공용 DNS로 전달하는 대신 부정 응답을 반환하는 것입니다.

선택은 구체성에 따릅니다. 여러 프라이빗 네임스페이스가 겹치면 가장 구체적으로 일치하는 영역이 이기고, 선택된 하위 영역에 없는 이름에 대해 더 넓은 프라이빗 상위가 두 번째 기회를 얻지 못합니다. 전달 규칙은 한 겹을 더합니다. 도메인별 Resolver 규칙이 프라이빗 호스팅 영역 연결을 이길 수 있기 때문입니다. 영역이 비어 있다고 결론 내리기 전에 연결과 규칙을 나열하세요.

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

두 명령 모두 영역을 소유한 계정의 자격 증명이 필요하고, 두 번째는 첫 번째에서 얻은 영역 ID가 필요합니다. 본인의 ID로 바꾸세요. 위의 자리 표시자는 의도적으로 실제 값이 아닙니다.

프라이빗 영역이 이기는 이유

영역을 VPC에 보이게 하는 것은 연결이며, 그 VPC의 리졸버가 이를 적용합니다. 클라이언트 트래픽이 오는 VPC에 연결되지 않은 프라이빗 영역은 아무 효과가 없고, 잘못된 VPC에 연결하면 잘못된 사용자 집단에 프라이빗 응답을 제공합니다. 레코드를 편집하기 전에 연결 목록을 확인하세요. 영역이 올바르면서도 보이지 않을 수 있습니다.

겹치는 네임스페이스는 혼란의 두 번째 원천입니다. example.net 에 대한 프라이빗 영역과 api.example.net 에 대한 프라이빗 영역이 모두 API 쿼리와 일치하며, 더 구체적인 쪽이 응답합니다. 좁은 내부 네임스페이스를 원할 때 유용하고, 좁은 영역에 더 넓은 영역에 있는 레코드가 없을 때 위험합니다. 프라이빗 호스팅 영역에 관한 고려 사항은 Route 53 문서 에서 하위 영역으로 넘어가는 동작과 규칙 우선순위를 모두 설명하므로, 두 번째 겹치는 영역을 추가하기 전에 읽을 가치가 있습니다.

이 중 어느 것도 공용 영역을 바꾸지 않습니다. 공용 리졸버는 여전히 공용 레코드에 올바르게 응답하며, 그래서 VPC 밖의 모든 사람에게 이 실패는 클라이언트 문제로 보입니다.

레코드를 추가하기 전에 네임스페이스를 선택하세요

내부 서비스의 새 계열에만 프라이빗 이름이 필요하다면 전용 프라이빗 하위 도메인을 주고 공용 상위는 그대로 두세요. 다음과 같은 이름은 internal.example.net 를 가릴 수 없고, www.example.net, 레코드가 없을 때의 영향 범위는 그 목적으로 만든 이름으로 제한됩니다. 대가는 기존 URL과 인증서가 새 이름과 맞지 않을 수 있다는 것입니다.

공용 사용자와 프라이빗 사용자가 같은 호스트 이름을 유지해야 한다면, 분할 뷰 DNS가 지원되는 설계이며 각 뷰에서 레코드를 명시적으로 유지해야 합니다. 레코드가 하나뿐인 넓은 프라이빗 영역은 그 영역 아래의 공용 의존성을 보존하지 않습니다. 의존성을 레코드가 하나뿐인 영역으로 바꿔 버립니다.

클라이언트 집단을 프라이빗 뷰로 돌리기 전에 애플리케이션이 실제로 호출하는 이름을 목록화하세요. 로그인 호스트, 정적 자산 호스트, 리디렉션 대상, API 엔드포인트가 먼저 깨지며, 보통 여러 팀의 레코드에 흩어져 있습니다.

리졸버 경로를 추적한 뒤 경로를 추적하세요

노트북이 프라이빗 뷰를 보는 것은 그 쿼리가 연결을 가진 리졸버에 도달할 때뿐입니다. VPN 서버의 hosts 파일을 편집해도 연결된 클라이언트에 아무것도 게시되지 않으며, 공용 리졸버로 구성된 클라이언트는 터널이 살아 있는 동안 계속 공용 응답을 받습니다. 클라이언트가 받은 리졸버 주소를 확인한 뒤 서버가 아니라 클라이언트에서 쿼리를 반복하세요.

이름이 확인되면 반환된 주소로 가는 경로를 별도 단계로 시험하세요. 예를 들어 ip route get 를 쿼리가 반환한 주소에 대해 실행합니다. 주소로 가는 경로가 없는 올바른 프라이빗 응답은 라우팅 문제이고, 레코드가 없다는 응답은 DNS 뷰 문제입니다. 둘을 하나의 문제로 다루면 유지되지 않는 수정이 나옵니다. 서비스의 TLS 호스트 이름과 인증서 검사는 변경하지 마세요. 프라이빗 주소는 연결이 가는 곳을 바꿀 뿐 어떤 인증서가 유효한지는 바꾸지 않습니다.

변경 노트에 영역, 연결, 리졸버, 확인한 이름을 기록하며 마무리하세요. 그러면 다음에 레코드를 추가하는 사람이 그 클라이언트 집단에 어떤 네임스페이스가 권위 있는지 알 수 있습니다.