Назад | Перейти на главную страницу

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

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

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

в corporate.su. сама зона присутствует на сервере как авторитетная 2001:db8::d, но нет ни одного упоминания NS сервер, который мог разрешить IP-адрес 2001:db8::d
рекорд для d.ns.corporate.su. отсутствует в списке NS серверы для corporate.su., но другой NS запись d.ns.example.net., присутствует, но все же решает 2001:db8::d
- что если d.ns.corporate.su.из родительской зоны, по-прежнему разрешается в дочерней зоне, но на другой IP-адрес?
- что если d.ns.corporate.su. даже не разрешается на моих авторитетных серверах вопреки клею в родительской зоне?

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

Я пробовал использовать dig +nssearch и dig +trace, но похоже dig страдает от различных загрязнений и проблем с бесшумным исцелением, и совершенно не делает очевидным, что на самом деле происходит за кулисами.

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

Судя по информации 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 и не будут выполнять рекурсивный запрос для enterprise.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.

Если мой преобразователь обнаружит конфликт, он отправит запрос в SOA (в вашем случае d.ns.cns.su).

не будет выполнять рекурсивный запрос для корпоративного.su »- что вы имеете в виду? зачем им это нужно? они уже авторитетны и имеют всю информацию о зоне

Не должны, это именно моя точка зрения. Если двое из них отправляют информацию о конфликтной зоне, они делают это с флагом 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- Ни один из полномочных серверов имен для корпоративного.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 разрешает вашему делегированному серверу имен, а не наоборот.