лень полностью вникать да и никто вроде бы не переводил такие неинтересные rfc касательно dns implementation. может кто-то ответит на конкретный простой вопрос ?

Есть домен в зоне .ru. на собственных серверах.
Добавляю дополнительно в записи еще одну NS-запись (неверную) и больше ничего не делаю - к регистратору в зону ru не лезу.
Спустя некоторое время ( TTL зоны) наблюдаю, что сервер провайдера начинает мне эту новую запись выдавать, причем в секции AUTHORITY RECORDS. То есть, кеш у провайдера обновился и он эту информацию получил с моего сервера.
Действительно ли информация, которую я вижу в ответе отражает реальную информацию о кеше сервера ?

Какой именно механизм в dns гарантирует отсутствие следующей ошибочной ситуации при переносе домена:

1 При первом обращении к домену, провайдер сохраняет у себя в кеше записи типа NS
2 В процессе переноса домена происходит изменение информации на корневых серверах зоны .ru
3 Клиент обращается к провайдеру. Провайдерский сервер, зная старые ns-записи, ttl которых не истек, снова обращается к старым серверам. Старый dns-сервер домена, который никто не трогал, все еще возвращает ответ и пометку авторитетности.
4 Провайдерский dns обновляет у себя у себя записи типа ns и обновляет им значение TTL без обращения наверх к серверам зоны .ru
5 проходит время не большее TTL в зоне. кеш у провайдера не выветривается.

пункты 3-5 повторяются бесконечно. В итоге пользователи провайдера открывают старый сайт, что, разумеется, неверно. Более того, на практике вроде сейчас бы и не наблюдается, но в интернете почему-то упорно считается, что время переноса домена может быть чуть ли не бесконечное.

olexandeНе совсем полна и потому не все ясно по условиям "первого" эксперимента. У кого авторитедный ДНС-сервер? Что хранится у регистратора и где меняете зону?


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

Перед переводом доменов на ..
Да как надо и так общеизвестно. Интересно разобраться, что происходит когда делают как не надо.



авторКогда я последний раз с этим разбирался (= в прошлом веке), кэширующие DNS-ы ничего не "обновляли", они или знали запись с непротухшим TTL или в случае протухания игнорировали её полностью и сначала спрашивали как раз первый непротухший сервер (в данном случае .ru)
dns он ведь на века!

Почему обязаны спрашивать именно у .ru ? как тогда объяснить результат эксперимента, где кеш "заражается" моей информацией, несоответствующей информации от серверов поддерживающих .ru ? где это прописано в rfc ? в таком случае, есть ли у named два разных кеша один для авторитетных данных полученных от .ru, а другой для данных, которыми я его заразил ?
Я видел два разных варианта работы серверов, когда обновляли и когда не обновляли. По версиям не могу сказать какой был софт, у bind модно (а может это security recomendations) скрывать версию.

olexandeВы меняете NS своей зоны, или в своей зоне указываете, что Ваш неправильный сервер, отвечает за некий, чужой домен?

Добавляю еще одну неправильную запись типа NS в своей зоне.
Эта информация оседает в кеше провайдера. Факт оседания виден по изменению TTL: я повторно запрашиваю у провайдера данные и они возвращаются каждый раз с уменьшенным TTL.

olexandeЕсли Ваш, авторитетный сервер дает не верную инфо, то КАК рядовой сервер может определить, где корректная инфо, а где "паленая"?
А это и есть суть моего вопроса. Как он определяет? Если сменю у регистратора информацию, то старый сервер в конце концов окажется не у дел.

olexande,автор
Старый сервер окажется не удел по причине:
и они возвращаются каждый раз с уменьшенным TTL.
А, да. упустил еще важный момент : я специально сделаю TTL у записей NS больше чем TTL у записей A, которые запрашивает клиент.
Что тогда? Зациклится навсегда?

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

olexande, смотрите, что получается :
когда истечет TTL записи A, сервер провайдера снова пойдет узнавать адрес сайта, но так как TTL записи NS в этот момент еще не истек, он должен обратиться в соответствии с актуальной информацией из кеша к неверному серверу и получить неверный ответ.

а советские газеты типа Хакер еще классик не рекомендовал.

olexande, в сухом остатке я вижу только совет читать исходники. Ну это и ежу понятно. Читать исходники долго и много.

iv_an_runetwindмой сервер обслуживающий зону - авторитетный. вся информация полученная с него сохраняется в кешах и отдается всем клиентам с пометкой "авторитетна".А будет ли сохранена пометка авторитетности после того, как кончится TTL записи, которую в своё время вернул сервер .ru?
Тут я не понял. Какой конкретно эксперимент нужно поставить?
Пометку авторитетности мои сервера выдают если на них хранится зона, будь она получена как slave или еще как, но главное не как результат рекурсивных запросов.