Является ли запись более безопасной, чем запись CNAME?

Question

У меня есть клиент, который использует наше веб-приложение. Их URL-адрес - portal.client.com. Когда я попросил их указать URL для CNAME app.company.com, они сказали, что это должна быть запись A.

Я утверждал, что CNAME был бы идеальным решением, потому что, если нам когда-либо понадобится изменить IP-адрес, мы можем просто сделать это в одном месте, а не связываться с каждым из наших клиентов, чтобы обновить свои записи DNS, экономя время и хлопоты для обеих сторон.

И вот ответ, который я получил от них:

Тот факт, что CNAME является перенаправлением URL-адреса, лучше всего установить запись A для веб-сервера провайдера хостинга. Это обеспечивает более безопасный подход, поскольку мы не можем гарантировать, что CNAME продолжит маскировать сторонние URL-адреса в отношении конечных пользователей на уровне браузера.

Теперь, ничего из этого не имеет смысла для меня. Прежде всего, CNAME не является перенаправлением URL-адреса ... Может ли кто-то пролить свет на то, как или в какой ситуации запись A будет лучшим или более безопасным подходом, чем CNAME, и если это применимо в этом случае.

Спасибо,

Answer 1

Я не могу придумать ситуацию, когда CNAME будет менее безопасным.

Можно утверждать, что поскольку псевдоним охватывает зону (client.com -> company.com), это небезопасно, поскольку конечная точка не находится под административным контролем client.com . Однако клиент якобы доверяет вам достаточно, чтобы использовать ваше приложение, так почему бы не поверить, что вы не испортили запись app.company.com .

С точки зрения системного администратора, я бы предпочел CNAME, как вы и предлагали, но вы можете просто сосать его, чтобы ваш клиент был доволен :).

Answer 2

Нет, запись CNAME не менее безопасна, чем запись А.

На самом деле, именно этот тип ситуаций и объясняет, почему CNAME существуют в первую очередь.

Из RFC 1034 Раздел 3.6.2.Псевдонимы и канонические имена:

хосты и другие ресурсы часто имеют несколько имен, которые идентифицируют один и тот же ресурс. Например, имена C.ISI.EDU и USC-ISIC.ARPA идентифицируют один и тот же хост.

Также следует отметить, что CNAME на самом деле не является перенаправлением URL. DNS-запросы выполняются до того, как будет установлено какое-либо соединение с сервером, и просто дайте вашему клиенту IP-адрес для использования в его сеансе. Клиент все еще знает, какой URL был первоначально запрошен.

Answer 3

В теории предполагающей приложение предназначено , чтобы быть нескольких арендуемых с различными доменами. ... нет никакой разницы.

имена не «перенаправляют», это псевдонимы. Это просто альтернативное название ресурса. После просмотра DNS ваше приложение не будет беспокоиться.

Это обеспечивает более безопасный подход, поскольку мы не можем гарантировать, что CNAME продолжит маскировать сторонние URL-адреса в отношении конечных пользователей на уровне браузера.

Не имеет смысла, технически говоря. Я бы посоветовал потерять контроль над именем A ... несколько менее страшно и небрежно, чем потерять контроль над IP-адресом, на котором работает ваше приложение.

Вы также не должны (но могли бы) иметь имя, указывающее на другое имя.

И нет никакой причины, по которой вы не можете порадовать этого клиента именем A, если вы ведете учетные записи достаточно хорошо, а других клиентов держите под именем. Просто возьмите плату за обслуживание и настройте свой SLA.

Answer 4

Запись A будет более безопасной, чем запись CNAME, в случае взлома DNS-серверов company.com. Кроме того, чтобы быть очень придирчивым, запись CNAME потребовала бы немного больше времени из-за дополнительного разрешения имен. Помимо этого, нет большой разницы, и на самом деле многие облачные сервисы Интернета, такие как Amazon Web Services, имеют привычку устанавливать CNAME для доменов клиентов.

Кроме того, URL-адрес - это что-то вроде http://portal.client.com/myapp/foobar.html. CNAME не может указывать на URL, только на имя хоста. Учитывая их ответ, кажется, что ваш клиент не знает, о чем он говорит. Возможно, вы захотите не бороться с их невежеством и, как предлагает @Joe, побаловать их установлением рекорда.