Следует ли использовать CNAME для поддоменов?

Я управляю несколькими веб-сайтами, которые в настоящее время имеют следующую конфигурацию DNS:

example.com      - A Record - Production Server IP
test.example.com - A Record - Test Server IP
www.example.com  - CNAME    - example.com
beta.example.com - CNAME    - test.example.com
dev.example.com  - CNAME    - test.example.com

Это правильное использование записей CNAME? Я посмотрел онлайн и не нашел четкого ответа. Некоторые люди утверждают, что записи CNAME являются плохими (однако им не ясно, почему это так) и предлагают следующую настройку:

example.com      - A Record - Production Server IP
test.example.com - A Record - Test Server IP
www.example.com  - A Record - Production Server IP
beta.example.com - A Record - Test Server IP
dev.example.com  - A Record - Test Server IP

Какой из них является лучшим подходом (и почему)?

Примечание. Для поддоменов не требуются собственные записи MX, поэтому здесь нет проблем.

domain-name-system cname-record Иосиф Стуртевант
источник

я чувствую, что это должен быть ответ вики. DNS так сложно понять, и этот принятый ответ все еще хорош 6 лет спустя?

the0ther

@ the0ther Да, даже сегодня подтвержденный ответ от Джеспера Мортенсена все еще действителен (даже если кто-то может поспорить о наименовании вещей или о правильных значениях TTL для использования, но это отдельные моменты из вопроса об использовании записей CNAME или нет ). DNS является 30-летним протоколом, поэтому основные вещи, такие как записи CNAME, не меняются со временем.

Патрик Мевзек,

Ответы:

Да, это правильное использование CNAME. В обсуждениях, в которых я принимал участие, аргументы имеют тенденцию идти так:

Против CNAME:

Существует (крошечное) снижение производительности, так как нисходящие кэши DNS должны выполнить 2 поиска DNS, один для CNAME и один для A-записи, на которую указывает CNAME.
Неясные, поддельные аргументы о том, что у CNAME меньше проблем с правами доступа или совместимостью.

В пользу CNAME:

Они обеспечивают чистую абстракцию между оборудованием (физическими серверами) и сервисами.
Они упрощают управление DNS - когда сервер перемещается, вам нужно изменить только одну запись.

Попробовав несколько разных способов сделать это, у меня теперь есть свой любимый стиль. Это:

Одна запись A для каждого физического сервера; с довольно низким TTL (возможно, 30 минут); давая серверу понятное для человека имя .
Один CNAME для каждой услуги; с высоким TTL (возможно, 24 часа); указывая на вышеуказанные имена серверов.
Как единственное исключение из вышеприведенных правил, корнем домена является A-запись, указывающая на балансировщик веб-сервера / веб-нагрузки. (Символ @ должен быть 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

Джеспер Мортенсен
источник

Спасибо, наконец, разумное мнение о CNAME, изложенное четко и кратко.

Тайлер

@Jesper Mortensen: не могли бы вы немного обновить ответ небольшим примером, особенно я не понял ваш 3-й пункт, когда вы говорите: «Единственное исключение из вышеприведенных правил, корень домена - это A-запись», вы уже в первом пункте сказано, что вы используете одну запись A для каждого сервера физического уровня. (Кстати, ссылки исчезли)

Марко Демайо,

@Marco Demaio: О «доменной записи A-root»: домен второго уровня company.com- это вершина зоны. Для этого нужна запись SOA. Таким образом, это должна быть запись A, а не CNAME - см. Serverfault.com/questions/170194/…

Джеспер Мортенсен

@ не обязательно иметь запись A; скорее, CNAME запрещен.

Майкл Хэмптон

Просто хочу добавить, что CNAME особенно полезны, если ваши серверы также поддерживают адреса IPv6, так как вам понадобится как минимум две записи на сервер (по одной записи A и AAAA каждая), поэтому используйте CNAME для поддоменов. в этом случае намного, намного проще. Если вы используете рекомендации Jesper для TTL (или у вашего DNS-провайдера хорошая автоматическая обработка), то не должно быть реального снижения производительности.

Харавикк

Да, это уместно.

Моя лучшая практика, которой делятся многие, - создание записи 1 A для каждого IP-адреса сервера; и использовать CNAMES для чего-либо еще.

Типичным примером будет:

server1.example.com.      IN A      192.168.0.1
server2.example.com.      IN A      192.168.5.2
www                       IN CNAME  server1
ftp                       IN CNAME  server1
beta                      IN CNAME  server2

Крис С
источник

Я знаю, что в этом вопросе они сказали, что почта здесь не проблема, но давайте предположим, что вы также используете почту, как бы вы работали с записями MX? Спасибо!

Марко Демайо

Запись MX будет также указывать на имя сервера. IN MX server1и для удобства я бы порекомендовал также настроить imapили popи smtpCNAME, возможно также mail, так как многие почтовые программы предполагают это. Настройка правильных записей SRV также является хорошей идеей, но, поскольку это относительно простой вопрос, записи SRV могут показаться немного сложными для простой конфигурации.

Крис С

Краткий комментарий, MXзаписи не должны быть CNAME, см. Serverfault.com/a/232243/2874 На практике это, вероятно, работает нормально, но, тем не менее, лучше этого не делать.

Джеспер Мортенсен

BIND откажется загружать зону, если вы укажете запись MX или SRV на CNAME ... Я, вероятно, должен был четко заявить, что запись MX должна указывать на запись A. Спасибо.

Крис С

@ChrisS, как насчет редактирования вашего ответа и четкого упоминания того факта, что запись MX не может указывать на запись CNAME?

Алексис Вилке