Как стать автором
Обновить

Комментарии 19

По моему скромному мнению - это "при вводе в браузер адреса www.google.com, он автоматически заменяется на google.com — это магия CNAME " не может быть магией CNAME. Это может быть магией 301 redirect, а DNS клиенту может только предоставить разрешение имени WWW.google.com в IP адрес через прослойку в виде cname, но никак не http редирект.

Добрый день! Да, вы правы, спасибо, что уточнили это. Сам переход осуществляется по 301 redirect, а CNAME лишь указывает, куда идти.

Нет, CNAME никак не указывает куда идти редиректу, это в 301 указывается, CNAME тут совсем не приделах. CNAME нужен лишь ждя того, чтобы для www.google.com не создавать отдельную А запись и потом при смене ip обновлять только A запить google.com, на www.google.com может вообще не быть редиректов и быть отдельный сайт, но в DNS это будет CNAME. Как можно было писать такую статью без знания базовых вещей?

Да, вы совершенно правы в описании механики CNAME. Пытался писать проще, чтобы не пугать новичков, на которых рассчитана статья) Спасибо за комментарии! Благодаря вам мы прояснили этот момент для людей, которые хотят погрузиться в тему глубже.

Этот ответ выглядит точь-в-точь как сообщение ChatGPT когда ей указывают на ошибку, забавно.

Ни фига себе. Тоже первая мысль, которая мне пришла в голову при прочтении. Может, это оно и есть?

Забавно, нас много, кому пришла такая же мысль :) Следующий вложенный ответ кстати тоже :))

Про редирект в браузере с www.google.com на google.com при помощи CNAME - полная чушь же

Запись CNAME нельзя добавить для домена второго уровня вроде selectel.ru или google.com.

А точно ограничение исходит от уровня домена, а не от наличия SOA записи?

Добрый день! Ограничение было введено для доменов второго уровня, так как для них всегда есть SOA запись у регистратора доменов. И зачастую у доменов третьего уровня и дальше отсутствуют какие-либо записи. Вы правы, главным ограничением является наличие каких-либо других записей у домена, как в третьем пункте.

Кажется, тут опять какая-то путаница. У регистратора вообще может не быть серверов DNS и, соответственно, записей. Регистратор - организация, которая обеспечивает внесение записей о домене на DNS-сервера верхнего уровня, которые совсем необязательно будут иметь отношение к регистратору. И обычно вносятся только записи NS, запись SOA будет уже на серверах для конкретного домена. Которые уже могут быть серверами регистратора, если он предоставляет такой дополнительный сервис, а могут быть и где-то в другом месте.

А реальный ответ на тему что будет если наплевать на это ограничение — описан у https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/
Ну и у Cloudflare также есть свое решение которое дает "просто" прописывать cname у домена и все будет работать. Если домен на их NS'ах.

Видел конструкции основанные на CNAME которые позволяют делегировать выпуск wildcard SSL сертификатов let's encrypt.

Аналогично CNAME помогает передать конфигурирование autodiscover.mail.domain провайдеру почты.

Бывают ТИПЫ записей DMARC, DKIM, SPF? Смешались в кучу, кони, люди.

Ну SPF кстати есть (был точнее) - https://www.rfc-editor.org/rfc/rfc4408

> This document defines a new DNS RR of type SPF, code 99. The format of this type is identical to the TXT RR [RFC1035]. For either type, the character content of the record is encoded as [US-ASCII].

Я может читал невнимательности, но можно сделать привязку к A / AAAA записи?

Скажем есть домен example.com с A и AAAA записями и два под-домена:

  • v4.example.com -- указывает только на A;

  • v6.example.com -- указывает только на AAAA;

Так можно сделать?

Да, v4 и v6 — это отдельные домены в такой ситуации. Можно сделать так, как вы указали, но тогда не будут использованы cname/alias — адреса придётся обновлять вручную.

Поделитесь в комментариях, с какими трудностями вы сталкивались при подключении DNS-записей. Мы выберем интересные случаи и постараемся их разобрать.

Чуть меньше года назад я обратился в тех.поддержку некоторого хостинга с проблемой импорта зоны из файла, который был выгружен из Cloudflare.
Импорт осуществлялся в панели хостинга через предлагаемую кнопку выбора файла зоны.
На это действие панель отвечала немногословной ошибкой о том, что "вот она случилась", без указания причин.
Порывшись в документации хостинга, нашел указание, что импорт возможен только соответствующего файла.
Чему должен соответствовать файл для импорта и в чем заключается несоответствие имеющегося файла пришлось разбираться.
Тех.поддержка указала на необходимость завысить минимальный TTL всех записей до 60 секунд (где-то присутствовало 1 сек), но импортирование все также не давалось.
Следующим днем причина была найдена после разбивки зоны (почти 300 строк) по типам записей и импортированием каждого типа по отдельности.
Проблема заключалась в наличии CAA-записей, которые хостингом не поддерживались.

На данный момент хостингом включена поддержка CAA и моя проблема импорта давным давно решена, но осадочек остался.

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

Просто оставлю это здесь:

;; Truncated, retrying in TCP mode.

; <<>> DiG 9.8.7 <<>> @ns1.selectel.org test7.site IN ANY +nostats +noquestion
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31332
;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; ANSWER SECTION:
test7.site. 86321 IN NS ns1.selectel.org.
test7.site. 86321 IN NS ns2.selectel.org.
test7.site. 86321 IN NS ns3.selectel.org.
test7.site. 86321 IN NS ns4.selectel.org.
test7.site. 3521 IN A 127.0.0.1
test7.site. 3521 IN SOA ns1.selectel.org. support.selectel.ru. 2023012752 10800 3600 604800 86400

И при это, в тот же самый момент:

; <<>> DiG 9.8.7 <<>> @ns1.selectel.org test7.site IN A +nostats +noquestion
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52620
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; ANSWER SECTION:
test7.site. 3538 IN A 62.122.170.171

Ничего не смущает?

Заодно интерес но про SERVFAIL-ответ ваших DNS-серверов после добавления "ALIAS-записи" со значением, ссылающимся на несуществующий в зоне домен. Ну предположим. Вы же сами придумали свои стандарты, и наплевали на существующие RFC. Вопрос, почему не REFUSED?

А про этот "туториал", перед тем как в корпоративном блоке что-то пубикуется, неужели у вас даже фактчекинга нет? Печально, если у прочитавших в голове все отложится так как здесь написано.

P.S. Как в описанном у вас кейсе с алиасом на CDN SSL-сертификат для своего домена установить? Или про https можно забыть?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий