Я недавно подумал о TTL нашего DNS. У нас есть записи A для наших серверов, а затем записи CNAME для имен клиентов. CNAME www.example.com указывает, например, на server-01.example.com. В случае сбоя мы устанавливаем TTL на 15 минут как для CNAME, так и для записи A.
Однако до меня доходит, что это может быть неоптимально. Несомненно, запись A должна быть 48 часов, а CNAME - 15 минут. CNAME просто указывает на server-02.example.com в случае сбоя. Запись A (теоретически должна быть кеширована довольно долго, потому что мы используем CNAME в качестве переключателя).
Просматривая Интернет, я обнаружил, что у многих людей CNAME длинный, а рекорд A короткий: CNAME и запись A имеют разные TTL. Какой будет кэшироваться?
Кажется, это противоречит тому, чего бы все хотели. Вопрос в том, работает ли DNS так, как я надеюсь, в том смысле, что TTL запроса CNAME является важным, если мне нужно срочно переключить серверы?
Предполагая, что запись вершины A для example.com. указывал на сломанный IP-адрес, большинство известных мне компаний изменили бы запись A и пропустили www полностью изменить:
www.example.com над example.com. (подсказка: большинство из нас этого не делает)Переходя к вашему связанный примерсравниваешь яблоки и апельсины. Записи DNS Apex в сценариях веб-хостинга являются серьезной проблемой из-за хорошо известная проблема с вершиной CNAME. В этом случае есть только два правильных выбора: либо запись вершины A изменяется по мере необходимости, чтобы указать ей действительный IP-адрес, либо вы полностью отказываетесь от записи вершины. Все, что находится между ними, является недоработанным и непоследовательным.
Все это несколько не относится к делу: если вы полагаетесь на ручные изменения записей для обеспечения высокой доступности для своей службы, ты делаешь что-то не так. IP-адрес, который посещает веб-браузер, должен быть балансировщиком нагрузки, произвольным адресом, CDN или провайдером веб-хостинга, который может обеспечить такую высокую доступность, если ваши собственные фермы серверов не могут. Несколько записей адресов также могут работать, если вы уверены, что основные приложения, использующие их, следуют за RFC 6724 руководящие принципы (т.е. самые популярные веб-браузеры), но многие приложения ленивы и просто используют первую возвращенную запись адреса.
Ради аргумента, давайте рассмотрим Цепочка Google CNAME по существу, не помещая его в контекст вашей исходной проблемы. Это будет выглядеть знакомо, поскольку это текст моего первоначального ответа:
Тип записи здесь не имеет значения. Если запись необходимо часто менять, у нее должен быть очень низкий TTL. Если его не нужно часто менять, понятно, что ему не нужен низкий TTL, и вы можете использовать все, что вам удобно.
Никто (кроме Google) не может комментировать, почему Google хочет ghs.l.google.com IN A чтобы иметь более низкий TTL, чем указывающие на него записи CNAME. Вы не можете делать никаких выводов, не понимая их более крупный дизайн, и дизайн это то, что диктует ваши движущиеся части.
Я согласен.
Пока «реальные серверы» имеют стабильные IP-адреса, записи A должны иметь длинные TTL. Сохраняйте TTL записей CNAME на низком уровне, чтобы обеспечить быстрое переключение на другой реальный сервер в случае сбоя или чего-либо еще.