У меня есть клиент, который использует наше веб-приложение white label. Их url — portal.client.com. Когда я попросил их указать url на CNAME app.company.com, они сказали, что это должна быть запись A.
Я утверждал, что CNAME был бы идеальным вариантом, поскольку, если нам когда-либо понадобится изменить IP-адрес, мы сможем сделать это в одном месте, а не связываться с каждым из наших клиентов для обновления их DNS-записи, что сэкономит время и избавит обе стороны от лишних хлопот.
И вот какой ответ я от них получил:
Тот факт, что CNAME является URL-перенаправлением, наилучшим подходом является установка записи A на веб-сервере хостинг-провайдера. Это обеспечивает более безопасный подход, поскольку мы не можем гарантировать, что CNAME продолжит маскировать сторонний URL, насколько это касается конечных пользователей на уровне браузера.
Теперь все это не имеет для меня смысла. Прежде всего, CNAME — это не URL-перенаправление... Может ли кто-нибудь пролить свет на то, как или в какой ситуации запись A будет лучшим или более безопасным подходом, чем CNAME, и применимо ли это в этом случае.
Спасибо,
решение1
Я не могу представить себе ситуацию, в которой CNAME был бы менее безопасным.
Можно утверждать, что поскольку псевдоним охватывает зону ( client.com-> company.com), это небезопасно, так как конечная точка не находится под client.comадминистративным контролем . Однако клиент, как предполагается, доверяет вам достаточно, чтобы использовать ваше приложение, так почему бы не довериться тому, что вы не испортите запись app.company.com.
С точки зрения системного администратора я бы предпочел использовать CNAME, как вы предложили, но вы можете обойтись и без него, оставив своих клиентов довольными :).
решение2
Нет, запись CNAME не менее безопасна, чем запись A.
На самом деле, именно для таких ситуаций и существуют CNAME.
ОтRFC 1034 Раздел 3.6.2. Псевдонимы и канонические имена:
Хосты и другие ресурсы часто имеют несколько имен, которые идентифицируют один и тот же ресурс. Например, имена C.ISI.EDU и USC-ISIC.ARPA оба идентифицируют один и тот же хост.
Также следует отметить, что CNAME на самом деле не является URL-перенаправлением. DNS-запросы происходят до того, как будет установлено какое-либо соединение с сервером, и просто предоставляют вашему клиенту IP-адрес для использования в его сеансе. Клиент все еще знает, какой URL был изначально запрошен.
решение3
ВтеорияпредполагаяВаше приложение разработано для многопользовательской работы с различными доменами. ... особой разницы нет.
cnames не«перенаправления», онипсевдонимы. Это просто альтернативное название ресурса.ПрошлоеDNS-поиск вашему приложению неинтересен.
Это обеспечивает более безопасный подход, поскольку мы не можем гарантировать, что CNAME продолжит маскировать сторонний URL-адрес с точки зрения конечных пользователей на уровне браузера.
Технически говоря, это бессмысленно. Я бы считал потерю контроля над именем A... лишь немного менее ужасной и безрассудной, чем потеря контроля над IP-адресом, на котором работает ваше приложение.
Также не следует (но можно) иметь cname, указывающее на другое cname.
И, что ж, нет причин, по которым ты не можешь сохранитьэтотклиент доволен именем A, предполагая, что ваш учет достаточно хорош, и оставляя других клиентов на cname. Просто добавьте плату за обслуживание и скорректируйте свой SLA.
решение4
Запись A будет более безопасной, чем запись CNAME, в случае, если DNS-серверы company.com будут скомпрометированы. Также, чтобы бытьоченьпридираясь, запись CNAME потребует немного больше времени из-за дополнительного разрешения имени. Кроме этого, особой разницы нет, и на самом деле многие облачные интернет-сервисы, такие как Amazon Web Services, имеют привычку устанавливать CNAME для доменов клиентов.
Также URL-адрес — это что-то вродеhttp://portal.client.com/myapp/foobar.html. CNAME не может указывать на URL, только на имя хоста. Учитывая их ответ, похоже, что ваш клиент не знает, о чем говорит. Вы можете не бороться с их невежеством и, как предлагает @Joe, потакать им в установке записи A.