Когда я смотрю свой домен на http://www.intodns.com, вот проблема, которую я получаю:
КЛЕЙ не был отправлен, когда я спросил у ваших серверов имен ваши NS-записи. Это нормально, но вы должны знать, что в этом случае требуется дополнительный поиск записи A, чтобы получить IP-адреса ваших записей NS. Вы можете исправить это, например, добавив записи A к вашим серверам имен для зон, перечисленных выше.
Но у меня есть записи A для всех моих серверов имен в каждой записи зоны:
ns1.example.com. IN A <IP>
ns2.example.com. IN A <IP>
Как мне решить эту проблему с клеем?
Связующие записи - это специальные записи A, которые необходимы, когда сервер имен для домена DNS сам находится в том же домене.
Например, если ваш домен - example.com, а ваш сервер имен - ns.example.com, вам необходимо создать «приклеивающую» запись A для ns.example.com в следующей по высоте зоне DNS, в данном случае в зона "com". Это нужно сделать через вашего регистратора.
Это необходимо, потому что на запросы DNS для серверов имен (записи NS) всегда отвечает имя, а не IP-адрес.
Без связующей записи, если бы был сделан запрос для записей A www.example.com, сервер имен, обслуживающий «com», вернул бы NS-запись для example.com как ns.example.com (не IP), а исходный запрос не может быть разрешен, потому что любая дальнейшая попытка разрешить ns.example.com просто обратится к ns.example.com.
Проблема с GLUE на корневых DNS-серверах заключается в следующем:
example.com имеет записи DNS ns1.example.net и ns2.example.net в качестве серверов NS. Власть .com, в которой преобразователь DNS будет искать доменное имя, НЕВОЗМОЖНА предоставить IP-адреса для ns1.example.net и ns2.example.net, потому что они не находятся в его власти.
Чтобы исправить это, домен .com должен использовать NS-серверы .com. Таким образом, example.com будет использовать ns1.example-2.com и ns2.example-2.com, и все будет в порядке, поскольку орган .com может предоставить IP-адрес для сервера имен. Это экономит несколько циклов обращения к корневым DNS-серверам, так как в вашем случае для получения example.com теперь также необходимо спросить .net о example.net.
В моем случае все мои домены имеют собственные записи NS, поэтому для example.com у меня есть a.ns.example.com и b.ns.example.com, а для моего домена example.net - a.ns.example .net и b.ns.example.net.
Это требует дополнительных настроек, и не все хосты могут позволить вам это сделать. Вы можете застрять с тем, что у вас есть сейчас!
Попробовав сам инструмент и посмотрев, что он сообщает в некоторых знакомых мне доменах, я бы сказал, что к этому информационному сообщению может быть приведен ряд вещей (обратите внимание, что это буква «i» для информации, а не '!')
Например, в одной из моих зон есть серверы имен за пределами зоны, а из авторитетных серверов имен для зоны не все имеют записи A в своих авторитетных данных, которые должны быть возвращены в ответ.
Но это нормально - любой запрашивающий сервер имен в любом случае не должен доверять таким данным. Давным-давно вам бы это сошло с рук, но в наши дни каждый сервер имен может пытаться лгать и красться из зоны данных в ваш кеш.
Так что не беспокойся об этом. К тому времени, когда запрос достигнет вашего сервера имен, он уже найдет по крайней мере некоторые IP-адреса ваших серверов имен. Больше обращайте внимание на то, чтобы делегирование было таким же, как данные вашей собственной зоны (следующая запись, «Несоответствующие записи NS»), и чтобы ни одна из них не была «хромой» («Серверы имен хромые: все серверы имен, перечисленные на родительских серверах, авторитетно отвечают за ваши домен "- написано плохо, но вы хотите убедиться, что там стоит галочка.)