Что такое склейка доменов и как её правильно сделать?

Содержание:

1. Зачем нужна склейка доменов?
2. Как склеить доменные имена?
3. Как проверить склейку?

Склейка доменов — это процесс соединения нескольких доменов с целью направить их на единый сайт. Одно доменное имя становится основным, а остальные — зеркальными.

Для чего нужна склейка доменов:

• Для того, чтобы сменить доменное имя, не потеряв при этом трафик и параметры сайта. Например, вам не нравится старое название сайта и вы хотите его заменить
• Для перехода с HTTP на HTTPS протокол
• Для перехода с домена без WWW на домен с WWW и наоборот
• Для того, чтобы объединить сайты схожей тематики
• Чтобы соединить схожие в написании доменные имена. Например, чтобы посетитель случайно не перепутал адреса сайтов
• Для SEO . С помощью склейки возможно повышение индекса качества сайта на основном доменном имени, за счет присвоения показателей зеркальных доменов.

Если правильно склеить домены и настроить редирект при переезде сайта, пользователь не увидит страницу со старым доменом, при этом сохранятся посещаемость сайта и показатели поисковых систем.

Как склеить домены?

Есть два способа склейки доменов.

1. При помощи директивы Host (работает только для Яндекса) — наиболее легкий способ. Например, если требуется сделать handyhost.ru основным доменом, а сервис.рф — зеркальным:

• То на обоих сайтах в файле robots.txt в директиве Host указываем основной домен (https://handyhost.ru, указывается вместе с протоколом). Если домен кириллический, то указывается домен в кодировке Punycode
  Host: https://handyhost.ru
• Проверить указание на основной домен на всех сайтах
• Добавить в Яндекс. Вебмастер (webmaster.yandex.ru) новое доменное имя.

2. При помощи редиректа с HTTP-кодом 301 — код ответа 301 сообщает браузеру, что сайт или страница была перемещена навсегда. Данный метод позволяет суммировать показатели всех доменов и перенести целиком ссылочный вес.

• Как сделать перенаправление одного домена на другой читайте у нас на сайте
• Как сделать чтобы адрес отображался без WWW или наоборот с WWW можно посмотреть здесь. 

Как проверить склейку доменов?

В поисковой строке Яндекс пишется «url:Ваш_сайт.ru». Выдается один результат с вашим сайтом. Далее таким же образом пишем домен, который склеивали. Если в обоих случаях Яндекс находит один и тот же сайт, значит домены склеены.

Для Google вместо «url:», используется «info:».

Что такое склеивание доменов и как склейка зеркал влияет на продвижение сайта

Оглавление

1. org/ListItem»> Что такое зеркала
2. Индексирование зеркал
3. Зачем нужна склейка
4. Значение склейки для продвижения сайта
5. Как проверить, является ли сайт зеркалом
6. Способы проведения склейки доменов
7. org/ListItem»> Типичные ошибки, мешающие правильной склейке

Склейка доменов — процесс объединения нескольких доменных имен. После его выполнения выделяется один, который будет ранжироваться поисковыми роботами – главное зеркало.

Что такое зеркала

Для того чтобы понять, как происходит склеивание доменов и зачем оно нужно, стоит разобраться, что такое зеркала. Это сайты, которые являются полными копиями друг друга. У них совпадает контент на страницах с одинаковыми адресами (например, example.com/page.html и example1.com/page.html).

Кроме того, сайты могут считаться зеркалами, если со страниц одного настроен серверный редирект (перенаправление) на соответствующие им другого. Например, example.com/page.html перенаправляет на example1.com/page.html.

Индексирование зеркал

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

Зачем нужна склейка

Склейку применяют при наличии дублей сайта, например локальной версии, попавшей в индекс, а также при переезде сайта или переходе на защищенный протокол (SSL протокол, HTTPS-версия), который должен определяться поисковыми роботами как главное зеркало прежнего домена.

Значение склейки для продвижения сайта

На такие меры можно идти, если ресурс еще не очень прокачен. Когда сайт имеет хорошие позиции и переезжает на другой домен, склейка может навредить. В любом случае при склеивании доменов настраивается 301-редирект.

Как проверить, является ли сайт зеркалом

Для этого можно добавить сайт «Яндекс.Вебмастер». Если он будет опознан как неглавное зеркало, то сервис автоматически добавит его вместе с главным. Если у сайта нет зеркала, он будет отображаться в сервисе отдельно.

Способы проведения склейки доменов

С помощью директивы Host

Простой способ, позволяющий склеить одноименные и разноименные домены. Например, необходимо разместить сайт на адресах сайт.рф и resurs.ru, сделав его доступным по ссылкам с www. Порядок действий следующий:

• определить главное зеркало, которое будет продвигаться в будущем. Пусть это будет сайт.рф;
• настроить склеиваемые домены таким образом, чтобы они возвращали одинаковый контент. Недопустима ситуация, когда обновление данных идет только на одном сайте;
• на каждом домене во всех файлах robots.txt прописать директиву Host и указать адрес главного зеркала. В примере с кириллическим доменом запись выполняется в формате Punycode и выглядит следующим образом: Host: xn--80aswg.xn--p1ai;
• проверить, чтобы на всех адресах содержались одинаковые указания на главное зеркало. Проверять нужно не только resurs.ru/robots.txt и сайт.рф/robots.txt, но и www. resurs.ru/robots.txt, www. сайт.рф/robots.txt;
• зайти в «Яндекс.Вебмастер», в раздел «Сообщить о новом сайте», и добавить сайт.рф. Если указанное доменное имя ни с кем не склеено или уже является главным зеркалом, то появится сообщение о добавлении на индексирование. Если система сообщает, что сайт является неглавным зеркалом другого ресурса, то придется подождать переклейки, прежде чем домен начнет участвовать в поиске.

Если склейка осуществляется в паре имен с www и без www, то директиву прописывать не обязательно. Для этого в «Яндекс.Вебмастер» обычно используют инструмент «Главное зеркало».

Склейка и переклейка осуществляются при обновлении поисковых систем. Если домены разноименные, процесс может занять до 6 недель. Обратите внимание, что «Яндексу» для склейки зеркал достаточно директивы Host, а поисковая система Google ее не видит.

Северный редирект с HTTP-кодом 301

Этот способ подходит и для Google, и для «Яндекса». Редирект 301 (Moved Permanently – «перемещен навсегда») уведомляет поисковые системы о переезде страницы или сайта на новый адрес. Использование данного метода позволяет суммировать показатели обоих ресурсов и в полном объеме перенести ссылочный вес. (.*)$ http://www.site.com/$1 [R=301,L].

После склеивания информация о переезде ресурса на новый домен поступает в поисковые системы.

При работе с редиректом 301 стоит учесть следующие рекомендации:

• для поисковых систем наличие слеша и аббревиатуры www имеет большое значение. Необходимо выбрать версию с www/без www, со слешем/без слеша, с HTTP/HTTPS и настроить для них HOST и редирект;
• стоит избавиться от всех дублей страниц /index.php;
• ссылочный вес перейдет на новый домен только в том случае, если редирект 301 будет постраничным.

Типичные ошибки, мешающие правильной склейке

• На сайтах размещен разный контент.
• На всех склеенных доменах разная директива Host. В этом случае выбор главного зеркала для робота не очевиден.
• Не обо всех доменах было сообщено. Робот не индексирует неизвестные адреса.
• Одно или несколько доменных имен запрещены к индексированию в robots. txt.

Система доменных имен

— Что такое клейкая запись?

Ну, это три вопроса:

1. Что именно (но вкратце) представляет собой клейкая запись DNS?
2. Зачем они нужны и
3. как они работают?

Краткий ответ на первый вопрос, скорее всего, будет иметь мало смысла без контекста, учитывая несколько многословный ответ на два последних вопроса. Вот альтернативное объяснение с историческими ссылками на RFC, чтобы дать некоторый контекст терминологии, особенно:
RFC 822 «Стандарт формата текстовых сообщений ARPA в Интернете» 1982 г., https://www.rfc-editor.org/rfc/rfc822.html, в настоящее время устарел;
RFC 5322 «Формат интернет-сообщений» 2008 г., https://www.rfc-editor.org/rfc/rfc5322;
RFC 882 «Доменные имена — концепции и возможности» 1983 г., https://www.rfc-editor.org/rfc/rfc882, который предшествует и устарел;
RFC 1034 «Доменные имена — концепции и возможности» 1987 г.

, https://www.rfc-editor.org/rfc/rfc1034 и;
RFC 1035 «Доменные имена — реализация и спецификация» 1987, https://www.rfc-editor.org/rfc/rfc1035; промежуточный
RFC 952 «Спецификация таблицы хостов Интернета Министерства обороны США» 1985 г., https://www.rfc-editor.org/rfc/rfc952.html;
RFC 1123 «Требования к интернет-хостам — применение и поддержка» 1989 г., https://www.rfc-editor.org/rfc/rfc1123.html, особенно;
RFC 2181 «Пояснения к спецификации DNS» 1997 г., https://www.rfc-editor.org/rfc/rfc2181 и;
RFC 2535 «Расширения безопасности системы доменных имен», 1999 г., https://www.rfc-editor.org/rfc/rfc2535.

Теперь, кратко, к первому вопросу: «связующая запись» DNS — это разговорный термин, не определенный в RFC, для типа записи ресурса IP-адреса DNS, записи «A» или записи «AAAA». Запись IP-адреса также является «связующей записью», когда эта запись IP-адреса дает адрес, который связывает путь к общедоступному вторичному серверу протокола DNS делегированной «дочерней зоны»/«доменного имени», где, в частности, эта общедоступная вторичный DNS-сервер «доменное имя» для этой делегированной «дочерней зоны» также равно в и непосредственно в пределах этой дочерней зоны. И здесь — поскольку я не нашел это явно изложенным в RFC — ожидается, что сетевой администратор сделает вывод, что, когда делегированная «дочерняя зона» также находится в этой дочерней зоне и непосредственно находится под ее управлением, тогда родительская зона должна также предоставлять одну или несколько записей IP-адресов, которые, в конце концов, ссылаются на дочернюю зону , полномочные серверы протокола DNS. «Связующие записи» касаются взаимодействия «авторитетных» и «неавторитетных» серверов, где по дизайну , «родительская зона» является , а не авторитетной для «дочерней зоны».

И затем есть предостережение, поднятое Лададададой в вопросе «В чем разница между записями NS и записями клея?», о том, что на практике существует неопределенность, возможно, не вполне проясненная в RFC, относительно того, является ли какой-либо конкретный Клиент протокола DNS будет или не будет следовать пути, а затем проверит , что связанная дочерняя зона сервера протокола DNS также является полномочный сервер для этой дочерней зоны, эффективно проверяющий соответствие IP-адресов. Существует вероятность того, что IP-адрес «связующей записи» может привести к полномочному серверу с записью ресурса «Сервер имен», ведущей к различным , таким образом, несогласованным IP-адресам для одного или нескольких авторитетных DNS-серверов протокола для этого дочернего зона. Возможно, адрес сервера проверен. Возможно, адрес сервера не проверен, а IP-адрес устарел, и, возможно, файл зоны этого сервера также «наполовину» устарел, с правильными записями «Name Server», но обслуживает актуальные или иным образом неправильные ответы для других ресурсов. Конечно, это обстоятельство подразумевает административные ошибки DNS, так что это просто предостережение. Такого «не должно» быть на практике.

Ответы через RFC на последние два вопроса усложняются, когда от читателя ожидают «общеизвестности» и часто используется «перегруженная» терминология, когда на практике в обычном употреблении один и тот же термин используется в отношении двух , иногда больше, разные вещи или разные абстракции. Еще одна вещь, которую следует признать здесь, — это ранняя ассоциация в развитии обмена сообщениями в Интернете и системы доменных имен, а затем то, как эта ассоциация повлияла на использование терминологии обмена сообщениями в Интернете в RFC системы доменных имен как «общеизвестно» для тех времен.

В частности, это приводит к очень непоследовательному использованию термина «доменное имя» в различных документах RFC, термина, который в различных контекстах может означать либо:

1. «имя хост-домена», либо
2. «Доменное имя подзоны».

Эти термины могут быть выведены исторически из RFC. Как «общеизвестно», сам «хост» является одновременно 1) машиной с физическим сетевым интерфейсом и 2) интерфейсом IP-сокета операционной системы, которому был назначен IP-адрес. Термин «доменное имя хоста» взят из RFC 1123, в котором этот термин используется явно.

Термин «доменное имя подзоны» может быть получен из нескольких RFC. Мы видим «доменное имя» «дочернего домена», как первоначально в RFC 822, или «дочернюю зону» позже в RFC 2181, или «подзону», «доменное имя подзоны», как подразумевается в других RFC, особенно в RFC 1035. и RFC 2535.

Эти «доменные имена» — две очень разные вещи, обе из которых могут использоваться как:

1. значения для «имени владельца» в пакете данных протокола DNS и левая сторона «владелец записи ресурса «Главный файл» или «файл зоны», а также как
2. значение «кононического имени» RDATA в записи ресурса NS, MX или CNAME или в качестве «кононического имени» MNAME в записи ресурса SOA, в пакете данных и в правой части файла зоны, как в RFC 1034 и RFC 1035.

Особенно в раннем RFC 952 мы видим, что эти две разные концепции «домена» просто «смешаны вместе»:

 СПЕЦИФИКАЦИЯ ТАБЛИЦЫ ГРАММАТИЧЕСКОГО ХОЗЯИНА
  А. Разбор грамматики
  ...
     <имя_домена> ::= 
     <официальное имя хоста> ::= 
 

Другой вероятной областью путаницы является «Запись ресурсов NS», которая также имеет два очень разных значения, в зависимости от контекста. Мы можем прочитать RFC 2181, раздел 6.1, ниже https://www. rfc-editor.org/rfc/rfc2181#section-6:

6.1. Полномочия зоны
Полномочные серверы зоны перечислены в записях NS для источника зоны, которые вместе с записью Start of Authority (SOA) являются обязательными записями в каждой зоне. Такой сервер является авторитетным для всех записей ресурсов в зоне, которые не находятся в другой зоне. Записи NS, указывающие на вырез зоны, являются собственностью созданной дочерней зоны, как и любые другие записи для происхождения этой дочерней зоны или любых ее поддоменов. Сервер для зоны не должен возвращать авторитетные ответы на запросы, связанные с именами в другой зоне, которая включает в себя записи NS и, возможно, A в разрезе зоны, если только он не является сервером для другой зоны.

и обратите особое внимание на фразу «NS записи … являются обязательными записями в каждой зоне» и дополнительно обратите внимание:

За исключением случаев DNSSEC, упомянутых непосредственно ниже, серверы должны игнорировать данные, отличные от записей NS, и необходимые записи A для обнаружения серверов, перечисленных в записях NS, которые могут быть настроены в зоне на срезе зоны.

В то же время мы также читаем в предыдущем Разделе 6:

… Наличие среза зоны указывается в родительской зоне наличием NS-записей, указывающих происхождение дочерней зоны. Дочерняя зона не содержит явных ссылок на родительскую зону.

Таким образом, читателю остается сделать вывод, что в файле зоны существуют два очень разных класса NS Resource Record:

1. обязательные записи, имеющие ту же самую «метку», что и домен «исходный» зоны. себя, предоставляя «доменные имена хостов» самоописательных авторитетных общедоступных вторичных серверов протокола DNS. Они относятся к этой зоне и являются авторитетными . И
2. те необязательные записи, имеющие метки , а не точно соответствует исходному домену зоны и, таким образом, указывает теперь расширенные исходные домены дочерней зоны и связывает путь к общедоступным вторичным именам серверов протокола DNS для дочерней зоны. Они ссылаются на какую-то другую зону и не являются официальными . Эти записи являются лишь «наилучшей догадкой», учитывая, в частности, что эта родительская зона не может быть авторитетной для дочерней зоны.

Мы должны воспользоваться моментом и понять, что этот второй класс записей NS может , тогда также требует включения соответствующих адресных записей в качестве «связывающих записей», когда делегированная «дочерняя зона» также находится в этой дочерней зоне и непосредственно находится в ее пределах, как обсуждалось ранее. Мы также должны понимать, что эти точно такие же записи NS и связанные с ними «связующие записи» должны быть включены — можно предположить, что они «включены избыточно» — в файл зоны дочерней зоны для «имя домена подзоны» , как авторитетный выражение общедоступных вторичных серверов протокола DNS домена подзоны и их IP-адресов. Опять же, помните, что «родительская» зона никогда не является авторитетной для «дочерней» зоны, даже если файл родительской зоны включает и уже предоставил точно такую ​​же информацию — никогда для NS-записей дочерней зоны и никогда для любых других. тип записи ресурса дочерней зоны.

Итак, теперь ко второму вопросу, « Зачем нужны связующие записи?», мы должны сначала сказать, что, строго говоря, связующих записей не не нужен, совсем не нужен, при условии, что :

1. Файл зоны не описывает какое-либо дочернее «доменное имя зоны», включающее NS-записи ранее описанного второго класса, или
2. Файл зоны включает записи NS, описывающие дочернее «доменное имя зоны», , а также , общедоступные вторичные серверы протокола DNS для дочерней зоны , а не в и непосредственно под управлением в пределах , которые детская зона.

Если администратор сети не настраивает какую-либо крупную организацию, нуждающуюся в делегированных поддоменах, с собственными серверами DNS-протокола с самостоятельным администрированием, нет необходимости в какой-либо «связующей записи». И даже в этом случае крупная организация вполне может предусмотрительно распределить свои серверы протокола DNS за пределы любого делегированного поддомена, опять же, возможно, избегая необходимости в «связывающих записях», если адреса этих серверов уже будут разрешены в другом месте, возможно, каким-то внешним провайдером. .

«Связующие записи», скорее всего, необходимы для «тщеславного» домена или для небольшой организации, которая хочет администрировать оба своих собственных сервера протокола DNS, и файл зоны, используемый вышестоящим провайдером DNS организации, скорее всего их регистратор DNS. И даже в этом случае, скорее всего, только файл зоны регистратора будет иметь «клеевые записи», связанные с собственными DNS-серверами протокола их клиента, которые, вероятно, имеют номер , а не , который также используется клиентом для делегирования доменных имен подзоны.

Но, как будет рассмотрено в следующем ответе на третий вопрос, « как они работают» — « почему » немного сложнее. Работа DNS подразумевает следование по пути через иерархию компонентов домена, как описано в RFC 882, в разделе «Спецификации и терминология пространства имен», что в конечном итоге требует «связующего» IP-адреса от неавторизованного сервера к полномочному серверу, на каждый «вырез зоны». Если не ограничиваться «корневой» зоной, существует всегда режет зону по пути к нужному целевому «доменному имени». «Склеивающие записи» обеспечивают «связывание» зональных разрезов.

Здесь следует упомянуть, для исторического контекста, переходный механизм записи NS и записи Address. Обратите внимание, что запись NS содержит «доменное имя подзоны», «владелец» в левой части записи ресурса и «имя хост-домена», «каноническое имя» RDATA, в правой части. . IP-адреса здесь пока нет. Почему это? Мы можем вернуться к «общеизвестным сведениям» из устаревшего RFC 822 в разделе 6.2.3 в разделе https://www.rfc-editor.org/rfc/rfc822.html#section-6.2, в котором четко указано:

6.2.3. УСЛОВИЯ ДОМЕНА
Ссылка на домен должна быть официальным именем реестра, сети или хоста. Это символическая ссылка в поддомене имени. Иногда необходимо обойти стандартные механизмы разрешения таких ссылок, используя более примитивную информацию, такую ​​как адрес сетевого узла, а не связанное с ним имя узла.
…
Доменные литералы, которые относятся к доменам в ARPA Internet, указывают 32-битные интернет-адреса в четырех 8-битных полях, отмеченных десятичным числом, как описано в Запросе комментариев № 820, «Назначенные номера». Например:
[10.0.3.19]

 Примечание. ИСПОЛЬЗОВАНИЕ ДОМЕННЫХ ЛИТЕРАЛОВ НАСТОЯТЕЛЬНО НЕ РЕКОМЕНДУЕТСЯ. Это
       допускается только как средство обхода временных
       системные ограничения, такие как таблицы имен, которые не
       полный.
 

Или, перефразируя, «доменное имя» обычно , а не IP-адрес. Таким образом, RDATA записи NS является «доменным именем», а не IP-адресом, и отдельная запись Address связывает это «доменное имя» NS RDATA с записью ресурса «ARPA для Интернета» RDATA, фактическим IP-адресом. И тогда, следовательно, Address-запись в этом контексте тоже можно было бы назвать «клеевой записью», а NS-запись — нет. Этот второй класс записи NS равен 9.0003 всегда требуется , чтобы пометить «разрез зоны» в родительской зоне, но может потребоваться связанная адресная запись или, возможно, , а не , как обсуждалось.

Здесь есть еще одно замечание по терминологии, касающееся записи ресурса SOA и различия между «первичным» сервером протокола DNS и «общедоступным вторичным» сервером. В RFC 1035, раздел 3.3.13 «Формат SOA RDATA», по адресу https://www.rfc-editor.org/rfc/rfc1035#section-3.3.13, есть:

 MNAME  сервера имен, который был
                оригинальный или первичный источник данных для этой зоны.
Записи SOA не вызывают дополнительной обработки раздела.
 

Обратите внимание на прошедшее время: « было первоисточником». Опять же, мы должны воспользоваться моментом и понять, что очень часто ни один из общедоступных серверов протокола DNS не обязательно является также первичным сервером для зоны, а также что «первичный источник данных для этой зоны» даже не обязательно быть в открытом доступе. Обычно первичный сервер общедоступен, но это не обязательно. И при этом также возможно, что первичный сервер является общедоступным и только сервер для зоны, желательно иметь резервные серверы. Для упрощения администрирования нескольких серверов один первичный сервер может выполнить «перенос зоны» или «авторитетный перенос», «AXFR», на группу вторичных серверов. Если быть педантичным, то «первичный» сервер указан в записи SOA MNAME, и, следовательно, серверы, указанные в RDATA требуемого первого класса записей ресурсов NS, являются «общедоступными вторичными» серверами. Тем не менее, может случиться так, что имя SOA MNAME и имя NS RDATA также относятся к одному и тому же серверу.

Наконец, что касается третьего вопроса, « Как работают связующие записи?», полезно подумать о подразумеваемой работе протокола DNS при обмене данными между клиентом и различными серверами, обсуждаемом в RFC 1034, особенно в разделе 5 «Резолверы» в https://www.rfc-editor.org/rfc/rfc1034.html#section-5 и RFC 1035, раздел 7 «Реализация преобразователя», в целом, и, в частности, раздел 7.2, в https: //www.rfc-editor.org/rfc/rfc1035#section-7.2 :

Некоторые тонкости:

Резолвер может столкнуться с ситуацией, когда ни для одного из серверов имен, указанных в SLIST, нет доступных адресов, и когда в списке указаны именно те серверы, которые обычно используются для поиска собственных адресов. Эта ситуация обычно возникает, когда RR клеевого адреса имеют меньший TTL, чем NS RR, отмечающие делегирование, или когда преобразователь кэширует результат поиска NS. Преобразователь должен обнаружить это условие и перезапустить поиск в следующей зоне-предке или, альтернативно, в корне.

Клиент выполняет последовательность запросов, прокладывая себе путь через иерархию доменных имен, в основном разрешая компоненты поддоменов в IP-адреса, обычно сначала находя «доменное имя» «корневого» сервера, затем его IP-адрес, затем «глобальный домен верхнего уровня» сервер «доменное имя», затем его IP-адрес, затем «доменное имя третьего уровня», «доменное имя подзоны», делегируемое на данный момент родительским глобальным доменом верхнего уровня, и поиск IP Адрес DNS-сервера протокола этой зоны. Сервер для глобального домена верхнего уровня будет авторитетно предоставить «разрез зоны», указав «доменное имя подзоны». И тогда клиенту потребуется IP-адрес для этого сервера протокола DNS «имя домена подзоны» третьего уровня. Однако, как уже говорилось, в каждом «разрезе», следуя иерархии доменных имен, «родительская» зона — это , а не , авторитетный источник для IP-адреса сервера протокола DNS для «дочерней» зоны, по дизайну. . Все-таки клиенту нужен IP-адрес — откуда?

Клиент может начать следовать другому пути через иерархию доменных имен, выполняя поиск этого IP-адреса, который заканчивается только тогда, когда клиент идентифицирует сервер с «Источником полномочий» для IP-адреса сервера протокола DNS. указанное для доменного имени этой дочерней подзоны, и любую другую запрашиваемую запись. Но независимо от этого, при каждом «разрезе» из зоны в подзону клиент должен иметь «мост» от неавторитетного источника для IP-адреса сервера к «авторитетному» источнику для этого IP-адреса. Вот почему «связующую запись» можно назвать всего лишь «подсказкой» об IP-адресе сервера. Сервер родительской зоны предлагает «наилучшее предположение», «предложение», перенаправляя клиента с текущего сервера на «следующий» сервер, продолжая поиск клиентом сервера с «Источником полномочий», чтобы окончательно объявить авторитетно что это IP-адрес IP-адрес сервера DNS-протокола «имя хост-домена» для целевого «доменного имени подзоны».

«Связующие записи» обеспечивают этот IP-адрес «мостом» между неавторизованным исходным сервером и, в конечном счете, авторитетным исходным сервером . Позаботится ли клиент о том, чтобы убедиться, что IP-адрес текущего сервера действительно соответствует IP-адресу авторитетного сервера имен DNS для целевого «доменного имени подзоны», остается на усмотрение клиента. Надейтесь на лучшее — или подтвердите вручную. Можно было бы полностью исключить из файла зоны первый класс авторитетных NS-записей с самоописанием и по-прежнему предоставлять клиенту любую другую ресурсную запись, пока клиент просто «надеется на лучшее» и не на самом деле не проверять записи NS и связанные с ними записи Address.

См. также RFC 8499 «Терминология DNS» 2019 г., https://www.rfc-editor.org/rfc/rfc8499.html.

Система доменных имен

. В чем разница между записями NS и записями клея?

спросил 10 лет, 3 месяца назад

Изменено 7 лет, 5 месяцев назад

Просмотрено 6к раз

У меня есть две клеевые записи в Godaddy, например:

 NS1. MYDNSSERVER.COM
NS2.MYDNSSERVER.COM
 

И у меня есть три записи NS в моем домене:

 NS1.MYDNSSERVER.COM
NS2.MYDNSSERVER.COM
NS3.MYDNSSERVER.COM
 

1. Если у меня есть клейкие записи, зачем мне записи NS?
2. Дополнительная запись (NS3.MYDNSSERVER.COM) — это настоящий DNS-сервер, но по какой-то причине я не могу обновить эту запись как связующую. Может ли это вызвать какие-то проблемы?

• система доменных имен
• клейкая запись

1

Glue-записи — это «подсказки» IP-адресов, которые родительские серверы (т. е. не GoDaddy) предоставляют в дополнение к ответу, когда преобразователь спрашивает, какие записи NS предназначены для вашего домена. Они не являются авторитетным ответом. Записи, которые вы пометили выше как связующие записи, не являются связующими записями, однако GoDaddy, вероятно, использует эти записи, чтобы сообщить родительскому серверу имен, каким должен быть связующий элемент. Канонический ответ DNS описывает это намного лучше, чем я могу.

Некоторые преобразователи будут использовать связующие записи без двойной проверки, а некоторые будут запрашивать NS-записи с авторитетных серверов имен (те, которые предоставили в связующих записях ), чтобы убедиться, что они действительно верны.

По своему опыту я знаю, что PowerDNS относится к первой группе, а bind9 — ко второй. У меня нет опыта работы с другими резолверами.

Отсутствие записей NS на ваших серверах имен вызовет проблемы с bind9. Такие проблемы, когда любой провайдер, чей интернет-провайдер использует bind9не сможет зайти на ваш сайт.

Наличие дополнительной записи NS на ваших серверах имен, которой нет на родительских серверах имен, означает, что сервер имен получает меньше трафика, чем два других. В этой ситуации все наоборот, и bind9 будет использовать все серверы имен, а PowerDNS — нет.

4

Склеивающие записи — это записи IP-адресов ваших DNS-серверов, если вы размещаете свои собственные DNS-серверы. Запись NS — это тип записи в вашем файле зоны, который отслеживает имя хоста ваших серверов имен. Вам нужно устанавливать связующие записи только в том случае, если у вас есть DNS-серверы, которые управляют своими доменами. Вам необходимо установить записи NS для каждого принадлежащего вам домена. Подумайте о таких связующих записях: изначально Godaddy управляет вашими файлами зон, потому что Godaddy является авторитетным менеджером ваших файлов зон. Теперь, если вы хотите настроить свои собственные DNS-серверы для управления файлами зон, вам нужно отключить свои зоны от Godaddy. После того, как вы отсоединились от Godaddy, вам нужен способ рассказать миру, как вас найти, иначе никто не узнает, кто новые авторитетные менеджеры файлов вашей зоны. Клеевые пластинки теперь играют. Они похожи на сообщение, которое вы оставляете Godaddy, в котором говорится: «Эй, кто хочет найти мои товарищи по зонам, скажите им, чтобы они спросили меня (IP-адреса ваших новых DNS-серверов). Надеюсь, это немного объясняет, как они работают.