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

Источник

1 ответ

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

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

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

ЧаВо nic.ru фактически утверждает, что для вступления делегации в силу требуется от 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 и не будут делать рекурсивный запрос для corporate.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 в вашем случае).

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

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

Что касается записи 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. Ни один из полномочных серверов имен для corporate.su не является частью пути делегирования.

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

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

Ну, это действительно не так.

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

Без SOA, без делегаций.

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

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

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

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

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

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

Источник
Другие вопросы по тегам