Что будет, если

пп. 1, 2 - нормальный регистратор тебе не даст указать такие днсы

п.3 - ничего

пп. 1, 2 - нормальный регистратор тебе не даст указать такие днсы

Почему? А точнее зачем?

1 и 2 - зависит от регистратора. в общем случае бардак.

1 и 2 - зависит от регистратора. в общем случае бардак.

Я знаю что зависит от регистратора. Мне интересно чем бардак череповат...

На самом деле ответ волшебно прост: в SOA указываются NS-сервера являющиеся авторитетными для данной зоны.

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

Часть клиентов не сможет разресолвить имена, поскольку будет периодически на них нарываться.

2. Что будет, если среди NS записей домена не перечислен один из серверов, на которые домен делигирован (при условии что мгновенная синхронизация обеспечивается внешними средствами)?

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

3. Что будет если в SOA записи указано что-то левое, в качестве mname?

Не будут работать передачи зон. По умолчанию принимающий сервер не принимает данные зоны от сервера не перечисленного в SOA. Это можно конечно изменить, отредактировав параметры уведомлений

В догонку:

В RFC 1035 говорится

«MNAME - <название домена> сервера имен являющегося источником оригинальных или первичных данных для этой зоны»

Так что если что-то левое будет здесь, то данные с такой зоной скорее всего (!) не примет партнер по репликации.

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

Часть клиентов не сможет разресолвить имена, поскольку будет периодически на них нарываться.

В процессе какой процедуры клиенты, будут использовать нерабочие сервера указанные в зоне? Как я понимаю, процедура такая: в качестве рекурсора хотим узнать где http://www.example.com для этого спрашиваем сервер обслуживающий зону .com о серверах, обслуживающий example.com, он возвращает список серверов на которые example.com делегирован, и у одного из них спрашиваем A запись от http://www.example.com. Список NS записей из самой зоны в этой процедуре не задействован никак. Где я не прав?

2. Что будет, если среди NS записей домена не перечислен один из серверов, на которые домен делигирован (при условии что мгновенная синхронизация обеспечивается внешними средствами)?

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

В русских реестрах можно делегировать на любые name-сервера без тестирования... Но и фиг сним. Понял.

3. Что будет если в SOA записи указано что-то левое, в качестве mname?

Не будут работать передачи зон. По умолчанию принимающий сервер не принимает данные зоны от сервера не перечисленного в SOA. Это можно конечно изменить, отредактировав параметры уведомлений

Ага... ясно...

он возвращает список серверов на которые example.com делегирован, и у одного из них спрашиваем A запись от http://www.example.com. Список NS записей из самой зоны в этой процедуре не задействован никак.

Именно так. Но есть тонкость: если в SOA сервера имен не совпадают с делегацией, то возможна ситуация, когда твой сервер не будет считаться источником достоверных данных для партнера по репликации. Произойдет это потому, что ДНС-сервер (партнер по репликации) местами и временами еще и клиент.

он возвращает список серверов на которые example.com делегирован, и у одного из них спрашиваем A запись от http://www.example.com. Список NS записей из самой зоны в этой процедуре не задействован никак.

Именно так. Но есть тонкость: если в SOA сервера имен не совпадают с делегацией, то возможна ситуация, когда твой сервер не будет считаться источником достоверных данных для партнера по репликации. Произойдет это потому, что ДНС-сервер (партнер по репликации) местами и временами еще и клиент.

Репликацию я специально вынес за скобки вопроса в самом начале, предположив, что репликацией все name сервера заняты сами, каким-то образом....

информация о зоне становится несогласованной между разными серверами. с какого спросят, такой ответ и будет.

информация о зоне становится несогласованной между разными серверами. с какого спросят, такой ответ и будет.

Я могу на своем сервере в своем NS'е поднять зону microsoft . com. В результате несогласование между разными серверами будет, а бардака — не будет. Потому что мой сервер никто спрашивать не будет (ну кроме меня и тех кого я туда сумею послать).

Так вот, вопрос, в результате какого технического процесса кто-либо может начать спрашивать name сервера, указанные в самой зоне, но не указанные в зоне вышележащей? Если такой кейс есть, то на него надо выявить. Если нет то ситуация ничем не отличается то поднятия зоны microsoft . com на сервере ns1.pupkin.ru

В DNS-ответе несколько полей, в том числе Authority section. DNS сервер пишет туда данные исходя из NS записей в его зоне. В исходном rfc 1034 даны примеры ответов с пустой Authority section, достаточно флага AA (Authority Answer). Но сейчас, вроде, сервера заполняют это поле, анализируют ли его клиенты я не знаю.

Единственное, что есть в rfc 1034 касательно NS-записей это случай, когда запрос касается CNAME, причём CNAME ссылается на другой домен, но оба этих домена обслуживаются одним DNS-сервером. Тогда в одном ответе даётся и резолвиг CNAME и резолвинг A записи в ip адрес. Аторитетность ответа по резолвингу CNAME даётся флагом AA, авторитетность резолвинга A-записи подтверждается полем Authority section. Авторитетность влияет на кеширование.

Нашел ответ в офлайне:

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

1. Идет в родительскую зону, и спрашивает там про нашу зону, ему выдают ns'ы.

2. Идет по выданным ns'ам и спрашивает че надо. Вместе с ответом получает athority section со списком серверов обслуживающих эту зону (то есть те NS которые перечислены в самой зоне) и кеширует их.

3. При следующем запросе обращается к одному из закешированных серверов, в том числе на тот который указан в зоне но не указан в родителе.

Следствия из этого такие:

а. Если указанный в зоне но не указанный в родителе сервер не работает — ничего страшного, резолвер спросит другого.

б. Если указанный в зоне но не указанный в родителе сервер работает не правильно, то резолвер может вернуть неправильный ответ.

в. Если NS указан в родителе, но не указан в самой зоне, то повторные запросы к нему не пойдут, и так же возможны какие-то дополнительные взбрыки зависящие от реализации сервера.

Вот...

А mname в SOA таки нужен только для динамического обновления, и на функционирования внешних кеширующих резолверов влиять не должен.

Зачем нужны NS-записи и MNAME в SOA? (комментарий)

Зачем нужны NS-записи и MNAME в SOA? (комментарий)

Зачем нужны NS-записи и MNAME в SOA? (комментарий)

Идет в родительскую зону, и спрашивает там про нашу зону, ему выдают ns'ы.

Это должно происходить только если сервер родительской зоны авторитетен для зоны о которой мы спашиваем. Второй вариант - настройки forwaders. Этот параметр отправляет запрос на указанные в нем сервера ДО того как ресолвер полезет на домен точка и вниз по дереву.