Как я могу исправить проблему «без клея» с поиском DNS?

Когда я смотрю свой домен на http://www.intodns.com , я получаю следующую проблему:

КЛЕЙ не был отправлен, когда я спросил у ваших серверов имен ваши NS записи. Это нормально, но вы должны знать, что в этом случае требуется дополнительный поиск записей A, чтобы получить IP-адреса ваших записей NS. Это можно исправить, например, добавив записи A к своим серверам имен для зон, перечисленных выше.

Но у меня есть записи A для всех моих серверов имен в каждой записи зоны:

ns1.example.com. IN A <IP>
ns2.example.com. IN A <IP>

Как я могу исправить эту проблему КЛЕЯ?

Клеевые записи - это специальные А-записи, которые необходимы, когда сервер имен для домена 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.

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

Попробовав сам инструмент и увидев, что он сообщает с некоторыми доменами, с которыми я знаком, я бы сказал, что это может быть несколько вещей, которые приводят к этому информационному сообщению (обратите внимание, что это «я» для информации, а не '!')

Например, в одной из моих зон есть серверы имен за пределами зоны, а из доверенных серверов имен для зоны они не все имеют записи A в своих доверенных данных, которые должны быть возвращены в ответе.

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

Так что не беспокойся об этом. К тому времени, когда запрос достигает вашего сервера имен, он уже нашел по крайней мере некоторые из IP-адресов ваших серверов имен. Будьте более обеспокоены тем, что делегирования совпадают с данными вашей собственной зоны (следующая запись, «Несоответствующие записи NS»), и что ни одно из них не является «хромым» («Серверы имен хромают: все серверы имен, перечисленные на родительских серверах, отвечают за ваши полномочия». домен "- плохо сформулировано, но вы хотите убедиться, что есть галочка.)