Несоответствие в NS и связующем звене записывает в родительской зоне, где каждый NS является все еще подлинным

Проблема в том, что ваш домен все еще не делегирован.

Судя по тому, что я вижу в информации Whois для домена, вы зарегистрировали его сегодня. Ваш домен зарегистрирован, но еще не делегирован;

whois corporate.su | grep state
state:         REGISTERED, NOT DELEGATED

В nic.ru FAQ фактически указано, что для того, чтобы делегирование действительно вступило в силу, требуется от 6 часов до нескольких дней.

При этом вы говорите. кажется, что в файле зоны много записей NS, когда я запрашиваю один из ваших серверов имен, которые скоро будут делегированы и уполномочены .

Всего у вас 9 записей NS.

dig +noall +answer @ns4.linode.com corporate.su ns
corporate.su.       86400   IN  NS  ns5.he.net.
corporate.su.       86400   IN  NS  d.ns.corporate.su.
corporate.su.       86400   IN  NS  d.ns.cns.su.
corporate.su.       86400   IN  NS  ns5.linode.com.
corporate.su.       86400   IN  NS  ns4.linode.com.
corporate.su.       86400   IN  NS  ns4.he.net.
corporate.su.       86400   IN  NS  ns2.linode.com.
corporate.su.       86400   IN  NS  ns2.he.net.
corporate.su.       86400   IN  NS  ns3.he.net.

Вы должны понимать, что все эти 9 серверов имен будут полномочными серверами имен. Это означает, что они ответят флагом AA и не будут выполнять рекурсивный запрос для корпоративного.su.

Пять серверов имен, которые вы включили в форму регистрации, являются серверами делегированных имен.

whois corporate.su | grep nserver
nserver:       any.ns.cns.su.
nserver:       d.ns.corporate.su.
nserver:       lon.ns.cns.su.
nserver:       ns2.he.net.
nserver:       ns4.linode.com.

Из них только d.ns.corporate.su потребует связующих записей в родительской зоне.

Причина в том, что для разрешения любых других делегированных серверов имен для вашего домена преобразователю не требуется знаю, как разрешить ваш домен. (т. е. циклические зависимости.)

Делегированные серверы имен должны фактически соответствовать авторитетным серверам имен. Поэтому вам следует проверить свою зону и удалить записи NS, которых нет в ваших регистраторах.

Или наоборот ... но опять же ... наличие 9 делегированных серверов имен и / или полномочного сервера имен - это излишне.

---

Ответ на комментарии;

что происходит, когда есть несоответствия имен между зонами

Если несоответствие между двумя авторитетными серверами имен, тогда у вас довольно небольшая проблема ... обычно, SOA будет преобладать .

Если мой резолвер обнаруживает конфликт, и иметь всю информацию о зоне

Не должны, это именно моя точка зрения. Если двое из них отправляют информацию о конфликтной зоне, они делают это с флагом AA ... Я должен считать само собой разумеющимся, что то, что они отправляют мне, является правильной информацией.

Что касается записи Glue, в вашем случае она все еще не проблема ... ваш домен НЕ делегирован.

dig @a.dns.ripn.net d.ns.corporate.su

; <<>> DiG 9.8.1-P1 <<>> @a.dns.ripn.net d.ns.corporate.su
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35421
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;d.ns.corporate.su.     IN  A

;; AUTHORITY SECTION:
su.         3600    IN  SOA a.dns.ripn.net. hostmaster.ripn.net. 650151100 86400 14400 2592000 3600

;; Query time: 150 msec
;; SERVER: 193.232.128.6#53(193.232.128.6)
;; WHEN: Wed Feb 13 21:30:42 2013
;; MSG SIZE  rcvd: 96

Вы должны заметить здесь 3 вещи.

1- Этот ответ был авторитетным (флаг AA) и иметь всю информацию о зоне

Не должны, это именно моя точка зрения. Если двое из них отправляют информацию о конфликтной зоне, они делают это с флагом AA ... Я должен считать само собой разумеющимся, что то, что они отправляют мне, является правильной информацией.

Что касается записи Glue, в вашем случае она все еще не проблема ... ваш домен НЕ делегирован.

dig @a.dns.ripn.net d.ns.corporate.su

; <<>> DiG 9.8.1-P1 <<>> @a.dns.ripn.net d.ns.corporate.su
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35421
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;d.ns.corporate.su.     IN  A

;; AUTHORITY SECTION:
su.         3600    IN  SOA a.dns.ripn.net. hostmaster.ripn.net. 650151100 86400 14400 2592000 3600

;; Query time: 150 msec
;; SERVER: 193.232.128.6#53(193.232.128.6)
;; WHEN: Wed Feb 13 21:30:42 2013
;; MSG SIZE  rcvd: 96

Вы должны заметить здесь 3 вещи.

1- Этот ответ был авторитетным (флаг AA) 2- Он не предлагал записи NS в разделе полномочий 3- Для вашей зоны по-прежнему нет SOA

Это означает, что 1- В вашем домене на данный момент нет никаких Glue-записей. 2- Ни один из авторитетных серверов имен для enterprise.su не является частью пути делегирования.

Глядя на ваш вопрос, вот некоторые исправления:

Например, если b.dns.ripn.net. родительской зоны su. говорит, что мой корпоратив.су. контролируется сервером d.ns.corporate.su.

На самом деле это не так.

dig @b.dns.ripn.net corporate.su soa

Нет SOA, нет делегирования.

что, если d.ns.corporate.su. из родительской зоны все еще разрешается в дочерней зоне, но на другой IP-адрес?

что, если d.ns.corporate.su. не разрешается даже на моих авторитетных серверах, вопреки клею в родительской зоне?

Я предлагаю вам прочитать ответ, который я предоставил именно для этой ситуации на meta.serverfault.com

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

Что делать, если у меня есть несколько таких NS-записей в родительской зоне моих серверов домена что все авторитетно отвечают на запросы относительно моей зоны, но все или некоторые из них имеют какое-то несоответствие в именах своих записей в фактической дочерней зоне, что противоречит родительской зоне?

С DNS ваша SOA всемогуща. Связанные записи должны соответствовать тому, что SOA разрешает вашему делегированному серверу имен, а не наоборот.