Почему корень домена не может быть CNAME и другие полезные кусочки о DNS

pochemu koren domena ne mozhet byt cname i drugie poleznye

В этой публикации будет использован приведенный выше вопрос DNS, dig, A записи, CNAME записи, и ALIAS/ANAME записи с точки зрения начинающего. Итак начнем.

Сначала некоторые определения

  • Система доменных имен (DNS): общая система для преобразования памятного домена (example.com) в IP-адрес (93.184.216.34). IP-адрес сервера, обычно веб-сервера, на котором хранятся файлы, необходимые для отображения веб-страницы.
  • DNS-сервер (также известный как сервер имен или сервер имен): использует программное обеспечение DNS для хранения информации об адресах домена. Существует несколько уровней – принадлежащие каждому провайдеру, корневому (всего 13 во всем мире), домену верхнего уровня (TLD, например, ‘.com’) и DNS-серверам уровня домена.
  • Доменное имя: домен (пример) в сочетании с TLD (.com). Термин «домен» часто используется как синоним имени домена, хотя они разные. Покупая «домен» у регистратора или торгового посредника, вы приобретаете права на конкретное доменное имя (example.com) и любые субдомены, которые хотите создать (my-site.example.com, mail.example.com и т.д.) .

Поток запросов высокого уровня

Поток высокого уровня происходящего при вводе «example.com» в своем браузере можно упростить, чтобы удалить прыжки к DNS-серверам ISP, Root и TLD, как показано ниже:

-Yu9MR65z19xx2TDl-6phT7soy3g3KNgjArX
Упрощенный поток запросов DNS, больше можно увидеть в более подробном потоке

Домен обычно имеет два или более серверов имен, содержащих записи, касающиеся доменного имени (example.com).

Можно сохранять много типов записей, большинство из которых могут иметь несколько записей для каждого типа:

  • A: адресные записи, сопоставляющие доменное имя с IP-адресом
  • CNAME: каноническая запись имени Используется для псевдонима одного доменного имени (или имени субдомена) в другое. Мы рассмотрим это более подробно позже.
  • MX: Записи Mail eXchange, сообщающие агентам доставки электронной почты, куда они должны доставить вашу электронную почту
  • TXT: гибкие текстовые записи, для хранения строк для разных целей.
  • SOA: единая запись Начало авторитета на верхнем уровне домена. Содержит конкретную необходимую информацию о домене, например его основной сервер имен
  • NS: серверы имен, связанных с доменом

Когда устройство отправляет запрос, который достигает сервера имен, сервер ищет в узле записи домена A запись и связанный сохраненный IP-адрес (example.com: 93.184.216.34). Затем он возвращается на устройство, чтобы использовать его для отправки запроса на правильный веб-сервер для получения запрошенной веб-страницы или ресурса.

Использование ‘dig’

dig (регистратор информации домена) является инструментом командной строки для запросов к DNS-серверам. Эта команда обычно используется для устранения неисправностей или, как сейчас, чтобы понять больше о настройке системы.

$ dig example.com приводит к длинному ответу, напечатанному на терминале, выход по умолчанию подробно описан здесь, который нас интересует ANSWER SECTION.

;; ANSWER SECTION:
example.com.       72703      IN     A       93.184.216.34

И вот мы видим это example.com возвращает an A запись о 93.184.216.34. Иногда доменов будет больше одного A запись, если более одного веб-сервера могут предоставить необходимую информацию.

Есть еще! Если мы попробуем некоторые другие примеры, мы скоро увидим, что появляется еще одна распространенная запись: CNAME.

$ dig www.skyscanner.net:

;; ANSWER SECTION:
www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net.
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

Использование +short флажок позволяет нам четко видеть сложившийся путь:

$ dig www.skyscanner.net +short

www.skyscanner.net.edgekey.net.
e11316.a.akamaiedge.net.
23.217.6.192

CNAME

А CNAME запись позволяет использовать имя домена в качестве псевдонима для другого канонического (истинного) домена.

Когда DNS-сервер возвращает a CNAME запись, он не вернет его клиенту. Скорее, он снова будет искать возвращенное доменное имя и, в свою очередь, возвращает A IP-адрес записи. Эта цепочка может продолжать много CNAME глубокие уровни, но затем испытывает незначительное снижение производительности от нескольких поисков до начала кэширования.

Простой пример этого может быть, если у вас есть сервер, на котором вы храните все свои фотографии. Обычно вы можете получить доступ к нему через photos.example.com. Однако вы также можете захотеть, чтобы он разрешил доступ через photographs.example.com. Один из способов сделать это возможным – добавить a CNAME запишите эти точки photographs к photos. Это означает, что когда кто-нибудь посещает photographs.example.com им будет предоставлено то же содержание, что и photos.example.com.

Использование запроса $ dig photographs.example.com мы увидели бы:

photographs.example.com    IN   CNAME photos.example.com
photos.example.com         IN   A     xx.xxx.x.xxx

Важно отметить, что CNAME этот кусок с правой стороны. Левая сторона – это имя или метка.

Другое распространенное использование для www субдомен. Приобретя example.com вам, вероятно, также нужны пользователи, которые вводят www.example.com чтобы увидеть то же содержимое.

Здесь следует заметить, что example.com может называться вершинным, корневым или открытым доменным именем.

Одним из вариантов было бы установить другой A запись, указывая на тот же IP-адрес, что и для example.com. Это вполне справедливо, и это то, что на самом деле example.com делает, но он плохо масштабируется. Что произойдет, если вам нужно обновить IP-адрес example.com указывает на? Вам также нужно будет обновить его для www субдомен и любые другие, которые можно использовать.

Если CNAME запись была использована для псевдонима www.example.com указывать на example.com тогда нужно будет обновить только корневой домен, поскольку все остальные узлы указывают на него.

Ограничение CNAME

В то время, когда были написаны стандарты DNS, были установлены некоторые правила, регулирующие их использование. RFC 1912 и RFC 2181 устанавливают, что:

  • SOA и NS записи обязательны для наличия в корневом домене
  • CNAME Записи могут существовать только как отдельные записи и не могут быть объединены с какой-либо другой записью ресурса (DNSSEC SIG, NXTи KEY RR записи исключены)

Это исключает а CNAME используется в корневом домене, поскольку эти два правила противоречат друг другу.

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

Примером этого приводит Cloudflare, описывая проблемы, с которыми они столкнулись с почтовыми серверами Microsoft Exchange после использования CNAME на их корневом домене:

Домены обычно обозначают серверы, обрабатывающие их электронную почту через так называемую запись MX. Проблема заключалась в том, что серверы Exchange… могли получить CNAME в корневой записи, а затем не должным образом уважать CNAME, установленный в записи MX. Вы не можете винить Exchange. Они работали в соответствии с предположениями, изложенными в спецификации DNS.

Здесь вы видите отрицательную сторону, которая может появиться в нескольких серверных программах или библиотеках. Потому что существует стандарт для a CNAME быть тем только запись в узле, других записей не ищут. Все остальные записи будут игнорироваться без уведомлений или сообщений об ошибках. Даже если an MX была установлена ​​запись для получения электронной почты, MX будет игнорироваться, как будто его не существует, поскольку CNAME оценивается первым. То же верно, если бы были A запись: the CNAME будет иметь приоритет и A запись не будет прочитана.

Современный интернет

Почему это проблема? Почему бы вы когда-нибудь хотели использовать a CNAME для вашего корневого домена? Вероятно, это конец пути при поиске IP-адреса веб-сервера, на котором размещено ваше содержимое?

В современном Интернет-ландшафте это уже не так. Мир сильно отличается от того, когда были написаны стандарты DNS.

Вы можете использовать поставщика платформы в качестве услуг (PaaS), таких как Heroku, и сохранять содержимое на их веб-серверах. Вы контролируете содержимое, но не инфраструктуру, а поставщик PaaS выполняет трудную работу по обслуживанию сети. Обычно они предоставляют вам URL-адрес (my-app.herokuapp.com), который является субдоменом их корневого домена, и вы можете просмотреть IP-адреса веб-серверов, на которых находится ваше содержимое. Но они полностью контролируются провайдером PaaS и изменяются без уведомления.

Масштаб и частота изменений серверной части, внесенных поставщиком PaaS, могут осложнить поддержку вашего корневого домена. A запись, указывающая на один IP-адрес. В идеале вы хотели бы сделать это:

example.com      IN   CNAME    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.example.com      IN   CNAME    my-app.herokuapp.com.
www.example.com  IN   CNAME    my-app.herokuapp.com.

чтобы позволить Heroku (или выбранному вами хост-провайдеру) управлять обновлением A зафиксировать, что CNAME пункты без каких-либо изменений, внесенных с вашей стороны. Однако, как мы теперь знаем, это нарушает спецификацию DNS, поэтому очень плохая идея.

Можно просто реализовать перенаправление 301/302 с example.com к www.example.com. Однако эта инструкция выполняется либо на веб-сервере (поэтому все еще возникает проблема необходимости использования фиксированного A запись в DNS, чтобы указывать на этот веб-сервер), или пользовательское перенаправление поставщика DNS (испытывающих осложнения с HTTPS).

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

Решение

Сейчас несколько поставщиков DNS разработали специальные решения для решения этой проблемы, в частности:

  • ALIAS на DNSimple
  • ANAME в DNS Made Easy
  • ANAME на easyDNS
  • CNAME (виртуальный) на CloudFlare

Это все виртуальные типы записей, предоставляемых CNAME схожее поведение, без всякого из недостатков. Точная реализация может отличаться, но на высоком уровне, когда DNS сервер видит один из этих типов виртуальных записей, он действует как разделитель DNS. Он следует за цепочкой, созданной псевдонимом, пока не решается на A запись (или записи) и возвращает их A записи на DNS-сервер. Это «сглаживает». CNAME цепи в A запись(ы) возвращена, и ее невозможно отличить от отправленного запроса. Запрос видит только чистый A запись, которая не нарушает спецификации DNS и не имеет никаких недостатков CNAME.

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

Для настройки DNSimple мы настроили бы, как показано ниже. Это решение имеет все преимущества псевдонимов доменных имен и ни один из рисков использования его на корневом уровне.

example.com      IN   ALIAS    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.

Спасибо, что прочли! ?

Как всегда, открыты для любых поправок или дополнительных пунктов.

Ресурсы

Добавить комментарий

Ваш адрес email не будет опубликован.