Конфликт наборы записей NS

Дженни D уже дает вам ядро проблемы, которую нужно решить (и действительно, вы должны использовать онлайн-инструменты поиска и устранения неисправностей, такие как Zonemaster или DNSViz, чтобы помочь вам в поиске и устранении проблем с DNS), но вкратце вы находитесь в одном случае, который называется "хромая делегация".

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

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

Давайте dig(!) далее в вашем конкретном случае, visitnc. com (вы должны поставить это в вопрос, а не в комментарий)

1) На авторитетных серверах имен вашего родителя, т.е. .COM, вот ответ:

$ dig @a.gtld-servers.net visitnc.com NS +noall +authority

; <<>> DiG 9.12.0 <<>> @a.gtld-servers.net visitnc.com NS +noall +authority
; (1 server found)
;; global options: +cmd
visitnc.com.        172800 IN NS ns2.rackspace.com.
visitnc.com.        172800 IN NS ns.rackspace.com.
visitnc.com.        172800 IN NS ns1.linode.com.
visitnc.com.        172800 IN NS ns2.linode.com.
visitnc.com.        172800 IN NS ns3.linode.com.
visitnc.com.        172800 IN NS ns4.linode.com.
visitnc.com.        172800 IN NS ns5.linode.com.

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

2) Теперь давайте опросим каждого из них, чтобы выяснить, имеют ли они одинаковую информацию.

Например, с:

$ for ns in ns.rackspace.com.  ns2.rackspace.com. ns1.linode.com. ns2.linode.com. ns3.linode.com. ns4.linode.com. ns5.linode.com. ; do dig @$ns visitnc.com NS +noall +answer ; done

Редактируя результаты для краткости, мы имеем в основном

нс. rackspace.com. и ns2.rackspace.com. полагают (возвращаясь как ответ, потому что настроены как таковые), что авторитетными серверами имен для вашего домена являются:

visitnc.com.        86400 IN NS ns.rackspace.com.
visitnc.com.        86400 IN NS ns2.rackspace.com.

-то есть они сами.

Но в то же время каждый из 5 Linode говорит:

visitnc.com.        86400 IN NS ns4.linode.com.
visitnc.com.        86400 IN NS ns3.linode.com.
visitnc.com.        86400 IN NS ns1.linode.com.
visitnc.com.        86400 IN NS ns2.linode.com.
visitnc.com.        86400 IN NS ns5.linode.com.

, что он сам по себе.

Но, как вы видите, ни один из них не отвечает тем же самым, что и родительский, поэтому у вас случай "lame delegation", что плохо, и вы должны исправить это, решив один раз навсегда, какая компания является обработчиком вашей настройки DNS, а затем изменить родительскую зону, чтобы перечислить только их сервера имён. Вам нужно будет пройти через вашего регистратора (whois visitnc.com | grep Регистратор: показывает, что это Network Solutions, LLC.), чтобы запросить это изменение. Это первое, что нужно сделать, а затем немного подождать, прежде чем пытаться устранить неисправности другого рода.

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

В качестве примера можно заметить, что записи SOA очень сильно отличаются, в том числе и для последовательного интерфейса. Серверы Rackspace отвечают:

visitnc.com.        300 IN SOA ns.rackspace.com. hostmaster.rackspace.com. (
                1527624042 ; serial
                3600       ; refresh (1 hour)
                300        ; retry (5 minutes)
                1814400    ; expire (3 weeks)
                300        ; minimum (5 minutes)
                )

Где Linode дают:

visitnc.com.        86400 IN SOA ns1.linode.com. mklauss.outpostdesign.com. (
                2018052959 ; serial
                14400      ; refresh (4 hours)
                14400      ; retry (4 hours)
                1209600    ; expire (2 weeks)
                86400      ; minimum (1 day)
                )

В связи с последним набором, а именно 86400 как TTL, так и отрицательное TTL, вам придется подождать по крайней мере это количество секунд (т.е. 1 день) после того, как вы что-нибудь измените и , увидев родительские авторитетные серверы имён, показывающие обновленную информацию. Обратите внимание, что родительское TTL на NS записях в два раза больше, поэтому пессимистический способ будет заключаться в том, чтобы подождать, по крайней мере, 48 часов после любого изменения, чтобы снова начать проверять вещи и устранять неполадки, которые должны быть исправлены.