Как правильно настроить запись CNAME / A при указании на виртуальную машину Azure?
У меня есть веб-приложение, размещенное в Azure, которое дает у меня есть «собственный» домен awesomeapp.cloudapp.net , и в настройках я вижу IP-адрес: 123.456.789
У нас есть домен www.awesomeapp .com , который указывает на целевую страницу, продвигающую компанию и службу приложения, и я настроил запись A следующим образом:
app.awesomeapp.com => 123.456. 789
, который работает нормально.
Проблема в том, что иногда нам нужно выключить виртуальную машину, и при повторном включении IP-адрес другой, поэтому запись A больше не работает. Допустимо ли, чтобы я установил такую запись CNAME?
app.awesomeapp.com => awesomeapp.cloudapp.net
, который решал бы проблему разных IP-адресов каждый раз, когда я включаю / выключаю машину. Это сработает? Это то, для чего используется CNAME? Это хорошая практика (с точки зрения производительности и безопасности?
Использование CNAME является довольно стандартной практикой с Azure по этой самой причине, это предотвратит проблему изменения IP.
Если по какой-то причине вам нужно использовать запись A, то вы захотите использовать зарезервированный IP, который останется неизменным, даже если вы перезагрузите или выключите ВМ.
.Против CNAME:
Существует (крошечный) штраф за производительность, так как последующий DNS кэш должен выполнять 2 DNS поиска, один для CNAME и один для A-записи, на которую указывает CNAME. Смутные, фальшивые аргументы о том, что у CNAME меньше "авторитета" или проблем с совместимостью.
В пользу CNAME:
Они обеспечивают чистую абстракцию между аппаратным обеспечением (физическими серверами) и сервисами. Они упрощают управление DNS -- когда сервер перемещается, вам нужно изменить только одну запись. Пробовав пару различных способов сделать это, теперь у меня есть личный любимый стиль. Это:
Одна запись A для каждого физического сервера; с довольно низким TTL (возможно, 30 минут); дающая серверу дружелюбное к человеку имя. Один CNAME для каждой службы; с высоким TTL (возможно, 24 часов); указывая на вышеупомянутые имена сервера. В качестве единственного исключения из правил, приведенных выше, корень домена является A-Record, указывая на веб-сервер / веб балансировщик нагрузки. (@ должна быть записью A). Я считаю, что эта установка работает хорошо. Она не позволяет выполнять дополнительный DNS поиск для CNAMES; и если сервер выходит из строя, я все равно могу изменить публичный DNS довольно быстро.
Вот (импровизированный) пример в синтаксисе BIND:
;name ttl class rr value
server01 30m IN A 192.168.0.3
server02 30m IN A 192.168.0.4
webmail 24h IN CNAME server01
extranet 24h IN CNAME server02
ftp 24h IN CNAME server02