☰

DNS 매핑 또는 CNAME 관련

tag-icon • tag-icon nginx domain-name-system
DNS 매핑 또는 CNAME 관련

각 고객이 자신의 애플리케이션 인스턴스를 얻는 작은 SaaS가 있습니다. 각 애플리케이션 인스턴스에는 다음과 같은 DNS가 있습니다.회사.example.com.

고객(예: X)이 나에게 대신에고객X.example.com 그는 자신의 애플리케이션 인스턴스를 자신의 도메인(예: app.his-domain.com)에 매핑할 수 있습니다.

하지만 처음에는 그에게 다음과 같은 CNAME DNS 레코드를 포함하도록 요청했습니다.

CNAME:

app.his-domain.com -> customerX.example.com

내 사이트에서 nginx에 대한 새 server_name을 추가합니다.

server {

server_name customerX.example.com app.his-domain.com;

proxy_pass: https://backend;

}

하지만 TLS 인증서 때문에 작동하지 않습니다..example.com 하위 도메인에만 해당!

질문:

이 DNS 매핑은 어떻게 작동하나요? 나는 그것에 대한 "공식 용어"를 모르기 때문에 그것에 대해 검색하는 것조차 어렵습니다. CNAME 아이디어는 DNS에 대한 제한된 경험에서 비롯되었습니다. 그럼 완전 말도 안 되는 이야기일 수도 있겠네요...

답변1

CNAMES와 HTTP 리디렉션을 혼동하고 있습니다. CNAME은 DNS 조회 중에 IP로 변환하지만 클라이언트가 서버에 대한 HTTPS 세션을 시작하면 여전히 HTTP 헤더에서 원래 DNS 이름을 사용하므로 NGINX가 다음에 대한 인증서를 제공하기 때문에 인증서 오류가 발생합니다. .example.com.

이 문제를 해결하기 위해 해야 할 일은 클라이언트에게 인증서를 발급하도록 요청 app.his-domain.com하고 NGINX가 사이트를 요청하는 클라이언트에 대해 이 인증서를 제공하도록 하는 것입니다 app.his-domain.com.

이 문제를 해결하는 또 다른 방법은 서버에서 리디렉션을 호스팅하는 것입니다. 여기서 NGINX는 클라이언트에게 301 Permanently Moved to 를 알려줍니다. 그러나 이는 클라이언트가 브라우저 주소 표시줄에서 client.example.com볼 수 있는 부정적인 측면을 가지고 있습니다 . client.example.com사용자 정의 도메인을 갖는 요점.

관련 정보