☰

DNS Mapping или, может быть, CNAME-связанный

tag-icon • tag-icon nginx domain-name-system
DNS Mapping или, может быть, 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 {

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 с сервером, он все равно будет использовать исходное DNS-имя в заголовках HTTP, поэтому вы получите ошибку сертификата, поскольку NGINX обслуживает сертификат для .example.com.

Все, что вам нужно сделать, чтобы исправить это, — попросить клиента выпустить сертификат app.his-domain.comи заставить NGINX предоставлять этот сертификат клиентам, запрашивающим сайт app.his-domain.com.

Другой способ исправить это — разместить на своем сервере перенаправление, при котором NGINX сообщает клиенту код 301 Permanently Moved to client.example.com, но у этого есть и отрицательный аспект: клиент затем увидит его client.example.comв адресной строке браузера, что сводит на нет весь смысл наличия собственного домена.

Связанный контент